Community
Participate
Working Groups
If you launch an application the java.library.path not only contains the directory of the JVM you are running with but many other directories as well. Some of those directories are from the JVM your Eclipse IDE is running in which causes problems eg to JavaFX-11 because it loads DLLs from an Old JVM (eg Java-8). For example this is a java.library.path I get when launching a simple Java-Application on JDK-11 from within the IDE. C:\Dev\Tools\openjdk-11_windows-x64_bin\jdk-11\bin; C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32; C:\WINDOWS;C:/Program Files/Java/jre1.8.0_172/bin/server; C:/Program Files/Java/jre1.8.0_172/bin; C:/Program Files/Java/jre1.8.0_172/lib/amd64; C:\Program Files (x86)\Common Files\Oracle\Java\javapath; C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem; C:\WINDOWS\System32\WindowsPowerShell\v1.0\; C:\Program Files\Git\cmd;C:\WINDOWS\System32\OpenSSH\; C:\Program Files\dotnet\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\; C:\Users\Tom Schindl\AppData\Local\Microsoft\WindowsApps;; C:\Program Files\Microsoft VS Code\bin; C:\Dev\Tools\eclipse-SDK-4.9-win32-x86_64\eclipse;;. The problem is that JavaFX-Dlls are not part of the jdk-11 install anymore hence they the JavaFX loads the one from JRE-1.8.0_172. The only current work around is to add -Djava.library.path=C:\doesnotexist so that the launcher does not the entries from above
Yes, It is behaving as expected. If java.library.path is not set, Launcher tries to get the attribute value for CLASSPATH_ATTR_LIBRARY_PATH_ENTRY from classpath which is as explained below : Attribute key for a classpath attribute referencing a * list of shared libraries that should appear on the * <code>-Djava.library.path</code> system property.
Please reopen if you jdt needs to act on this issue.
I think Eclipse should: a) not set a library.path at all (I've never ever set the library path for any Java application I'm launching) b) if it wants there should be a flag in the launcher telling the user that it sets one - in my case the hidden over smart behavior the launcher causes ANY JavaFX application to fail and most developers won't understand why
(In reply to Thomas Schindl from comment #3) > I think Eclipse should: > a) not set a library.path at all (I've never ever set the library path for > any Java application I'm launching) > b) if it wants there should be a flag in the launcher telling the user that > it sets one - in my case the hidden over smart behavior the launcher causes > ANY JavaFX application to fail and most developers won't understand why But, any idea why CLASSPATH_ATTR_LIBRARY_PATH_ENTRY was being set by the developer ?
no idea - i can only say I have not set that attribute ever myself so I guess it is set automatically somehow by the launcher system
Can you attach a sample project and steps to reproduce so that I can debug how it is being set and what will be the best option to overcome it. As, from the code analysis I am not able to understand what causes this attribute to be set.
Don't have a project setup to proceed.
We have experienced similar issues wich may also be caused by this problem: Our application ist based on Eclipse RCP and uses JavaFx as well. We have bundled a special AdoptOpenJDK 11.0.6 which has integrated JavaFX 13.0.2 (via JLink). Our application really needs (exactly) this JavaFx13 because it seems that there has been an interface change in FxCanvas. This special runtime is included in the "jre" folder of our RCP Application to make sure exactly this version is used. It seems that if there is an older Java-Version (for example Oracle Java9, which has an older JavaFx included) installed on the system, that older JavaFX is somehow being used via the java.library.path. This is fatal because it causes the JavaFX parts of our application to crash. We are currently working around this issue by specifying "-Djava.library.path=" in our own eclipse.ini However, this feels not like a clean solution for me: Something weird is going on, Eclipse should not be using anything outside the "jre" folder at all. Unfortunately, we also can not give a simple step-by-step example for the problem because it involves our whole application.
@Thomas, @Edwin, Can you check if the Native library location in Project -> Java Build path is set for your project?
We came across this issue in the APP4MC project now also. We have some visualizations based on JavaFX included in the Eclipse IDE based APP4MC product. After some discussion with Tom Schindl and further investigation I noticed that the Eclipse launcher seems to simply add the %PATH% on Windows to the java.library.path. In our case that variable is managed by central IT. Unfortunately because of "I don't really know why" multiple paths to different Java installations are part of the %PATH%. So the java.library.path contains the path to the Java installation that was used to start the application and all paths to Java installations set in the %PATH% environment variable. Why is the path to the Java installation that started the application added to the java.library.path? Why is the %PATH% environment variable added to the java.library.path? And actually, who is doing this? I have not set any variable in any of the projects. I do not even know CLASSPATH_ATTR_LIBRARY_PATH_ENTRY. The application simply stopped working today because of a probably incorrect system update. And getting to the point that a java.library.path setting that is generated in the background by some launcher that is not even known to a user was really hard. It would really be good to know why a value for java.library.path is set, and why it uses the calling Java installation and the whole %PATH%. Then we can discuss if this should be removed because it causes problems.
(In reply to Dirk Fauth from comment #10) > We came across this issue in the APP4MC project now also. We have some > visualizations based on JavaFX included in the Eclipse IDE based APP4MC > product. > > After some discussion with Tom Schindl and further investigation I noticed > that the Eclipse launcher seems to simply add the %PATH% on Windows to the > java.library.path. > > In our case that variable is managed by central IT. Unfortunately because of > "I don't really know why" multiple paths to different Java installations are > part of the %PATH%. So the java.library.path contains the path to the Java > installation that was used to start the application and all paths to Java > installations set in the %PATH% environment variable. > > Why is the path to the Java installation that started the application added > to the java.library.path? > Why is the %PATH% environment variable added to the java.library.path? > > And actually, who is doing this? I have not set any variable in any of the > projects. I do not even know CLASSPATH_ATTR_LIBRARY_PATH_ENTRY. The > application simply stopped working today because of a probably incorrect > system update. And getting to the point that a java.library.path setting > that is generated in the background by some launcher that is not even known > to a user was really hard. > > It would really be good to know why a value for java.library.path is set, > and why it uses the calling Java installation and the whole %PATH%. Then we > can discuss if this should be removed because it causes problems. Can you attach a project to explain? What stops working with simple Eclipse JavaIDE? Do you plain SDK or other plugins?
APP4MC is a modeling IDE based on Java, XText etc. There are many plug-ins included. You can download the product and even the sources from Eclipse. https://www.eclipse.org/app4mc/ To open a view with JavaFX you can create the democar example in APP4MC via New - > Example. Then open the democar.amxmi, in the editor do a right click on the Software Model (expand the tree first) and select "Open APP4MC Visualization" Using the Eclipse Java IDE would have the same issue for views with JavaFX. The problem can come up if you start the Eclipse application with a different Java version than you have configured in the PATH. Which is a common scenario for developers. Problematic is that it might not fail every time. Depends if the right DLL is found directly or not.
I have updated an example on GitHub [1] that brings up the issue aswell. The repository contains a simple E4 RCP application, the 'fx' branch contains the example to include a JavaFX control. Pre-requirements: - Java 8 with JavaFX included (e.g. Amazon Corretto 8) - e(fx)clipse installed in your Eclipse IDE - JavaFX available on your system and configured in the preferences to import the projects without errors. See [2] for further details - have multiple Java installations on your PATH - start the Eclipse IDE with another Java version than it is on your path 1. Checkout the sources from GitHub 2. Switch to the fx branch 3. Import the projects 4. Activate the target definition in org.fipro.eclipse.tutorial.target 5. Start the application via .product file in org.fipro.eclipse.tutorial.product If you for example have Java 8 on your PATH but start the application with Java 11, the issue should be reproducable. Unfortunately I am able to reproduce it always this way on one computer, but not on another computer. Not sure if it is related to some orderings in the PATH or something else. @Tom if you have an idea how this issue can be reproduced always, please add it to this ticket. [1] https://github.com/fipro78/e4-cookbook-basic-recipe/tree/fx [2] http://blog.vogella.com/2019/11/15/add-javafx-controls-to-a-swt-eclipse-4-application-eclipse-rcp-cookbook-update/
I don't think this has anything to do with JavaFX - any simple Java project should be enough to print out an invalid "java.library.path"
Well, then the question is, why is the PATH system environment variable together with the Java path that starts the application set as java.library.path. Is there a reason for doing this?
BTW, you can also find the java.library.path in the Eclipse IDE itself. Just open the About dialog: Help -> About Eclipse IDE -> Installation Details -> Configuration There you find also the java.library.path to be set to the Java installation that was used to launch Eclipse followed by the complete PATH
You can use this simple class and execute it from within an Eclipse IDE and you will see that there is a java.library.path set, although nobody has actively set it: public class Test { public static void main(String[] args) { System.out.println("java.library.path: " + System.getProperty("java.library.path")); } } Is it possible that JDT derives the java.library.path from the running instance, and that the running instance got the java.library.path value set by Equinox somehow?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
