Loading DLL from file not PATH
-
I added your function but I have the same result. And so I decided to do a little bit of testing. In Visual Studio I left the locations for
jdk1.8.0_202in properties, but I changed in PATH the location forjvm.dll. IF I'm using the PATH forjdk-17.0.1it is working fine, but as soon as I change it tojdk1.8.0_202it doesn't find the class anymore. -
There should be no difference between the two. But Without access to your system it is impossible to guess what might be the problem.
I just created 2 new VM's (Windows 10 x64), in one I installed Java SE 8 with Visual Studio, and I was getting the same thing, class not found, then I installed Java SE 17 and just like on host, no problem it is running fine. Then on the second machine I installed Java from oracle ^, which the user would do, and copied the working executable (with no errors) to it (after installing needed redistributable of curse) but I'm getting "jvm.dll" not found error.
-
I just created 2 new VM's (Windows 10 x64), in one I installed Java SE 8 with Visual Studio, and I was getting the same thing, class not found, then I installed Java SE 17 and just like on host, no problem it is running fine. Then on the second machine I installed Java from oracle ^, which the user would do, and copied the working executable (with no errors) to it (after installing needed redistributable of curse) but I'm getting "jvm.dll" not found error.
I just installed the 1.8 version of Java and rebuilt my project and it works fine. Have you checked that you are not trying to mix x86 and x64 code? Version 17 is x64 only, but 1.8 offers both. So if you have the x86 version installed that could be the problem.
-
Yeah, to be sure there isn't a problem with the installation, I even just uninstalled everything Java related, and reinstalled them. I don't even have a folder in "Program files (x86)", and in x64 I have these only 17 and 1.8 (and what I'm working on right now it is for x64 only anyway): https://i.ibb.co/X3xcDcf/image.png[^] When I have in PATH location from 1.8: https://i.ibb.co/K0vzM4J/image.png[^] And when I have in PATH location from 17: https://i.ibb.co/d23HNTv/image.png[^] It is the project from that tutorial with unmodified files. I even did some Java socket call tests from C++ and they worked fine with 17. That is kinda the main reason I need this Java/C++ combination for, as I already have some systems made in Java that this new project (made in Unreal Engine which is C++) will relay on.
Make sure that you build the C++ part and the Java part with the same version of Java, they may not be fully compatible across different versions. Also, rather than using pictures to post simple text information, please use copy and paste and add it to your question.
-
Make sure that you build the C++ part and the Java part with the same version of Java, they may not be fully compatible across different versions. Also, rather than using pictures to post simple text information, please use copy and paste and add it to your question.
Yeah that was the problem for saying that it can't find the class, I just added target and source and now it is working, but the second part is still a problem. I copied the released executable and the class file to a freshly created VM with only Java and redistributable installed and I'm getting the same error:
Example3.exe - System Error
The code execution cannot proceed because jvm.dll was not found. Reinstalling the program may fix this problem.
Off topic: They should add an image preview, because those are really useful.
-
I just installed the 1.8 version of Java and rebuilt my project and it works fine. Have you checked that you are not trying to mix x86 and x64 code? Version 17 is x64 only, but 1.8 offers both. So if you have the x86 version installed that could be the problem.
Yeah, to be sure there isn't a problem with the installation, I even just uninstalled everything Java related, and reinstalled them. I don't even have a folder in "Program files (x86)", and in x64 I have these only 17 and 1.8 (and what I'm working on right now it is for x64 only anyway): https://i.ibb.co/X3xcDcf/image.png[^] When I have in PATH location from 1.8: https://i.ibb.co/K0vzM4J/image.png[^] And when I have in PATH location from 17: https://i.ibb.co/d23HNTv/image.png[^] It is the project from that tutorial with unmodified files. I even did some Java socket call tests from C++ and they worked fine with 17. That is kinda the main reason I need this Java/C++ combination for, as I already have some systems made in Java that this new project (made in Unreal Engine which is C++) will relay on.
-
Yeah that was the problem for saying that it can't find the class, I just added target and source and now it is working, but the second part is still a problem. I copied the released executable and the class file to a freshly created VM with only Java and redistributable installed and I'm getting the same error:
Example3.exe - System Error
The code execution cannot proceed because jvm.dll was not found. Reinstalling the program may fix this problem.
Off topic: They should add an image preview, because those are really useful.
Valentinor wrote:
The code execution cannot proceed because jvm.dll was not found.
I think I have answered that more than once.
Valentinor wrote:
They should add an image preview
This has been rejected a number of times as it would be open to abuse by spammers.
-
Valentinor wrote:
The code execution cannot proceed because jvm.dll was not found.
I think I have answered that more than once.
Valentinor wrote:
They should add an image preview
This has been rejected a number of times as it would be open to abuse by spammers.
Richard MacCutchan wrote:
If the customer correctly installs the Java runtime then it will set the PATH variable with the correct details. Your code should then run correctly. I have done a test on my system and that is all that is needed as far as I can tell.
You did said this, and I've done it, even on 2 new separate VM's, installed Java and needed redistributable and on both I get the same error.
-
Richard MacCutchan wrote:
If the customer correctly installs the Java runtime then it will set the PATH variable with the correct details. Your code should then run correctly. I have done a test on my system and that is all that is needed as far as I can tell.
You did said this, and I've done it, even on 2 new separate VM's, installed Java and needed redistributable and on both I get the same error.
-
So you keep saying. But I cannot see what is happening on your system. I have tried multiple tests of this issue with Java versions 1.8, 14 and 17 and cannot recreate the problem you are having.
unknown 2022 06 16 11 59 - YouTube[^] Here is a video, first run is on host where I have jdk, Visual Studio..., and second is on VM.
-
unknown 2022 06 16 11 59 - YouTube[^] Here is a video, first run is on host where I have jdk, Visual Studio..., and second is on VM.
I owe you an apology. I do not have a VM to run this on so my reinstalls of Java were missing something that I had set up in the past. The jvm.dll is not in the bin directory of the JRE installation, but in a subdirectory named server. This was in my PATH variable and was not removed when I uninstalled one of the Java versions. So you need to add that location to the PATH variable manually. Sorry again for the confusion.
-
I owe you an apology. I do not have a VM to run this on so my reinstalls of Java were missing something that I had set up in the past. The jvm.dll is not in the bin directory of the JRE installation, but in a subdirectory named server. This was in my PATH variable and was not removed when I uninstalled one of the Java versions. So you need to add that location to the PATH variable manually. Sorry again for the confusion.
The thing is that when Java is installed it doesn't add some kind of dynamic link in PATH to where
jvm.dllis located, well it doesn't add one at all. Yes, if I'm compiling the class with 1.8 and then on VM I can manually add in PATH the server folder, but here is a problem, the user should not go though this process of opening variables and find PATH to add it there. A solution would be that when the app is opened, it would check if Java in installed, if it is not, then the user would be prompted to download it, or I have to search and see if you can legally distributeJavaSetup8uxxx.exefile and if you can the app would automatically run the file and the user would go though the process of installing Java. After Java is installed by either way then the app will search what version is installed to know what location to add in PATH, which it would do after knowing that. At this point the app will run fine. BUT then you run into another problem, if the user updates Java then the location will change forjvm.dll, so you would have to add another variable to PATH with the new location for it, and remove the old one. Adding a variable to PATH shouldn't be a problem, as Java and other programs do it too, I'll just have to see how that is done from C++ code. If this is actually the only way to do it, then I guess I can do it this way, but having another solution that wouldn't involve adding variables to PATH would have been better. -
The thing is that when Java is installed it doesn't add some kind of dynamic link in PATH to where
jvm.dllis located, well it doesn't add one at all. Yes, if I'm compiling the class with 1.8 and then on VM I can manually add in PATH the server folder, but here is a problem, the user should not go though this process of opening variables and find PATH to add it there. A solution would be that when the app is opened, it would check if Java in installed, if it is not, then the user would be prompted to download it, or I have to search and see if you can legally distributeJavaSetup8uxxx.exefile and if you can the app would automatically run the file and the user would go though the process of installing Java. After Java is installed by either way then the app will search what version is installed to know what location to add in PATH, which it would do after knowing that. At this point the app will run fine. BUT then you run into another problem, if the user updates Java then the location will change forjvm.dll, so you would have to add another variable to PATH with the new location for it, and remove the old one. Adding a variable to PATH shouldn't be a problem, as Java and other programs do it too, I'll just have to see how that is done from C++ code. If this is actually the only way to do it, then I guess I can do it this way, but having another solution that wouldn't involve adding variables to PATH would have been better. -
The thing is that when Java is installed it doesn't add some kind of dynamic link in PATH to where
jvm.dllis located, well it doesn't add one at all. Yes, if I'm compiling the class with 1.8 and then on VM I can manually add in PATH the server folder, but here is a problem, the user should not go though this process of opening variables and find PATH to add it there. A solution would be that when the app is opened, it would check if Java in installed, if it is not, then the user would be prompted to download it, or I have to search and see if you can legally distributeJavaSetup8uxxx.exefile and if you can the app would automatically run the file and the user would go though the process of installing Java. After Java is installed by either way then the app will search what version is installed to know what location to add in PATH, which it would do after knowing that. At this point the app will run fine. BUT then you run into another problem, if the user updates Java then the location will change forjvm.dll, so you would have to add another variable to PATH with the new location for it, and remove the old one. Adding a variable to PATH shouldn't be a problem, as Java and other programs do it too, I'll just have to see how that is done from C++ code. If this is actually the only way to do it, then I guess I can do it this way, but having another solution that wouldn't involve adding variables to PATH would have been better.I have been working on a possible answer to this. If you send me a personal email (see the link below this message) I can let you have the details, and the code. One of the things I have discovered is the the jvm.dll must be the same version as that of the javac compiler that buiolds the class file(s).
-
I have been working on a possible answer to this. If you send me a personal email (see the link below this message) I can let you have the details, and the code. One of the things I have discovered is the the jvm.dll must be the same version as that of the javac compiler that buiolds the class file(s).
I don't see any link it might have been cut, or it is hidden, but this is an old email I have that I don't care about spam so it is fine to make it public: Email removed
