a suitable version of java could not be found

[dmaziuk]

64-bit 5.5.1-3299, windows 10, corretto 11 jdk

[dmaziuk]

PS $JAVA_HOME is set, java -version in powershell or git bash returns

openjdk version "11.0.11" 2021-04-20 LTS
OpenJDK Runtime Environment Corretto-11.0.11.9.1 (build 11.0.11+9-LTS)
OpenJDK 64-Bit Server VM Corretto-11.0.11.9.1 (build 11.0.11+9-LTS, mixed mode)

and running davmail64.exe from command line prints

[info] Configured vm.location: (null)

[ringosham]

I have a different log. Davmail assumes the JVM to be in its current working directory rather than JAVA_HOME? Davmail version 6.0.0-3375

[info] Module Name: C:\Program Files\DavMail\davmail64.exe
[info] Module INI: C:\Program Files\DavMail\davmail64.ini
[info] Module Dir: C:\Program Files\DavMail\
[info] INI Dir: C:\Program Files\DavMail\
[info] Configured vm.location: ./jre/bin/server/jvm.dll
[info] vm.location item not found: ./jre/bin/server/jvm.dll
 [err] A suitable version of Java could not be found on your system, please install Java (64-bit) from http://java.com/en/download/manual.jsp

I can launch Davmail just fine using .jar. It's the .exe that is not working.

Edit: Just an additional note. JAVA_HOME does point to a JRE. Davmail is not reading it

[s-p-turner]

I also encountered this issue. One workaround is to create a davmail64.ini file in C:\Program Files\DavMail containing a vm.location parameter to your 64-bit jvm.dll, e.g.:

vm.location=C:\Program Files\Java\jre1.8.0_291\bin\server\jvm.dll

[ringosham]

@s-p-turner This works.

For better usability they should automatically generate this file, or at least tell us what we should do in a message box.

[dmaziuk]

well... $JAVA_HOME has been a de-facto standard only since, like, the 90s... but yes: so it installing a "default" config file with comments and instructions.

[s-p-turner]

From what I can gather, the 64-bit Java installer doesn't add anything to the environment that would allow DavMail to pick up the path to the jvm.dll file. The 32-bit Java installer does - it adds "C:\Program Files (x86)\Common Files\Oracle\Java\javapath" to the "Path" variable, and "javapath" is maintained as a shortcut to the directory containing the actual version installed.

To automatically generate the davmail64.ini file during installation in the absence of any environmental setup by Java-64, the DavMail installer would have to go searching for the 64-bit jvm.dll in "C:\Program Files\Java". But even if it successfully did that and created the .ini file, the path to the 64-bit jvm.dll would always contain the revision of Java installed, and the entry in the .ini file would need to be manually updated if/when you updated Java.

I think the 64-bit Java installer might be to blame here, rather than DavMail itself. But I do agree that the message contained in the error dialog could be rather more descriptive!

[vam103]

Well I tried all of the methods here with my AdoptOpenJDK JRE 16 on Windows 10 and version 6 is still saying it can not find java. Which is weird since version 5 can and runs quite well. AdoptOpenJDK even set the JAVA_HOME variable for the 64-bit version. i have tried with multiple versions of AdoptOpenJDK and it seems not to like it. Meanwhile the .jar works for version 6 with the same setup.

[s-p-turner]

I don't think davmail64.exe checks for the JAVA_HOME variable being set.

[JamieKitson]

The odd thing is that this is a change in 6.0. 5.5 worked fine for me, 6.0 needed the ini file fix.

[dmaziuk]

I don't think davmail64.exe checks for the JAVA_HOME variable being set.

It should.

$PATH is for executables so the 64-bit Corretto installer adds bin where java.exe is. It does not add bin/server, nor should it: there are no executables there. That, and java versioning, is why davmail64.exe should be looking in ${JAVA_HOME}/bin/server and not in $PATH or anywhere else.

Also the default ini file is not something to generate during install, it's a boilerplate config file that has all settings commented out (and hopefully commented). So the users familiar with the practice can trace vm.location to it without making a bug report.

Anyway, 6.0.0 works with the ini fix. Yay!

[s-p-turner]

I don't think davmail64.exe checks for the JAVA_HOME variable being set.

It should.

Agreed. I was just pointing out that I don't think it currently does. I extracted all the strings from the executable and JAVA_HOME just isn't in there.

Anyway, 6.0.0 works with the ini fix. Yay!

:-)

[vam103]

Well the jvm is found with the ini file. Probably the openj9 jre gets the error JVMJ9VM007E Command-line option unrecognised: java.base/sun.net.www.protocol.https=ALL-UNNAMED Seems to be down to a change that added [info] vmarg.2=--add-exports [info] vmarg.3=java.base/sun.net.www.protocol.https=ALL-UNNAMED Anyway more digging to do.

[dmaziuk]

try running java -jar davmail.jar instead of .exe, see what happens

[s-p-turner]

try running java -jar davmail.jar instead of .exe, see what happens

Executing davmail.jar did work for me. The issue was always with executing the .exe. But to use this as a definitive workaround meant modifying shortcuts etc. Therefore the davmail64.ini file workaround that I originally suggested was more suitable for me.

[dmaziuk]

.ini is in here: https://github.com/mguessan/davmail/tree/master/src/winrun4j/ but it remains to be seen if a) overriding vmarg.N with an empty string in the .ini will work and b) that particular setting is actually needed. By "see what happens" I meant the later: see if it runs without.

[arcanetrivia]

Same situation here: Win 10 (and also on my still Win7 computer at work); Davmail 6.0.0-3375 did not detect Java 8u291 64 bit; the .ini file workaround worked; as JamieKitson said, 5.5 used to work fine without this extra intervention.

[Reiner030]

I found the cause for this issue in my setup. Checking env path with echo %PATH% in cmd console I saw that I had several old (and one active) x86 and 64 binary java path entries so first match wins which is in old setups like my one mainly the x86 version path.

After removing this in system environment settings => environments variables => system variables it works as expected.

[b16r05]

I just want to report the problem is still not fixed.

Davmail: v 6.0.0.3375 Java SE RE: 8.0.301

I still get this error. Running 64 bit version did not work for me. Running the jar file worked.

I originally used chocolatey to install both. Then, I manually installed both. Uninstall or change program does not show any old versions of java.

echo %path% shows just C:\Program Files (x86)\Common Files\Oracle\Java\javapath (as this is a recent clean install)

There are no .ini files in the folder. Am I supposed to copy the .ini and 64.ini files (as well as the service.ini files) from the repo and place them in there?

[arcanetrivia]

I just updated Java and was confused for a second why this broke DavMail again, until I remembered I had hard-coded the path to the previous version in an ini file as described above. I tried the solution in Reiner030's comment about removing references to x86 Java in the Windows path but it didn't have any effect.

Is there any hope this will get fixed?

[Reiner030]

I use also DavMail 6.0.0-3375 but

$ java -version
openjdk version "11.0.11" 2021-04-20
OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)

which I fetched from https://adoptopenjdk.net/ last time.

[marcelser]

Same for me cleaning up path didn't have any effect. It still doesn't find the java version. Only ini file fix solved it for me. But as others have pointed out. If you update your java version you have to remember to update the .ini file.

This issue now open since 9 months and still no one has fixed it. It's not even assigned. When will one of the devs pick it up?

[konzertnr9]

I'm using vm.location=%JAVA_HOME%\bin\server\jvm.dll

[vam103]

Since I updated to version 6.0.1-3390 I have not needed the ini file while running IBM Semeru Open runtime 17 (IBM's version of AdoptOpenJDK with openj9) and it seems to be working on multiple machines running Windows 10.

[s-p-turner]

I'm using vm.location=%JAVA_HOME%\bin\server\jvm.dll

JAVA_HOME isn't populated in my setup - the variable is empty. I guess I could always populate it myself, add it to my environment and use it for the vm.location setting the .ini file. However, I'd still have to remember to change JAVA_HOME manually each time I updated Java. Therefore it would be no different to my current workaround of manaully editing the .ini file.

Is the JAVA_HOME environment variable supposed to be set up by the Java install?

[konzertnr9]

It's just my practice to check JAVA_HOME and update it where necessary when I update my JVM.

[marcelser]

That's not the question. The question is: should java installers set JAVA_HOME properly and davmail pick it up for locating java or not. If you're installing java from some archive then it's on your hands of course.

[konzertnr9]

The Oracle updator does not populate JAVA_HOME.

[Anguel]

I tried everything and only manually creating and manually populating C:\Program Files\DavMail\davmail64.ini worked. However, the big problem is that Java auto-updaters (I use Ninite for example) will again break it. Too bad such a problem stops many people from using this great software...

[arcanetrivia]

Yes, it's really rather irritating that I have to manually change this ini file every time Java is updated. But since this has been going on for over a year now, I'm starting to think the software has been abandoned...

[marcelser]

Unfortunately it seems the davmail devs don't care at all about this problem. This bug was opened 27th May 2021 which is now more then 1 year ago. No one is assigned to it it's not even confirmed. And yes it's a pain in the ass to always update the ini file but it seems it has lowest priority and will probably lets face it never be addressed