This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
There is a lot of interest in embedding JavaFX components in NetBeans Platform applications and IDE plugins. JavaOne 2012 had three talks about this, and there are several blogs about how to ship your own JavaFX runtime with your applications. NetBeans 7.3 ships an embedded JavaFX runtime, which could be exposed to allow easy integration without having to care about delivering a runtime. core.browser.webview defines an SPI (JFXRuntimePathProvider) to get hold of this or an alternative, registered JavaFX runtime. Currently there are only two implementations of that path provider. One checks for the bundled runtime libraries, the other reads runtime path from Preferences. These can currently only be utilized using reflection: http://netbeans.dzone.com/news/reusing-existing-netbeans-ide Usecases: 1. A developer wants to create a plugin for the IDE which uses JavaFX. I currently plan on doing so for my Box2D Plugin (https://github.com/eppleton/JBox2D-Support), because I've reached some limitations of Visual Library (rotation is not supported and hard to implement) that JavaFX doesn't have. 2. A developer wants to create an application that uses JavaFX features like the Charts. https://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=4801&tclass=popup Ideas for the API: The APi should allow to use JFXPanel to embedd JavaFX Scenes in NetBeans TopComponents. Right now this is only possible in three ways: - creating a Module that holds the jfxrt.jar and require JDK 7 u7 to be installed - creating a Module that holds the jfxrt.jar and ship with all native libraries - in 7.3 constructing a classloader via a implementation dependency and using reflection. A minimum/suboptimal solution would be to expose JFXRuntimePathProvider as a public API. I wouldn't suggest that, because it requires reflection, and complicates development, since there will be no editor support for JavaFX. The most convenient option from a developer perspective would be a module that exposes the classes from the bundled jfxrt.jar and doesn't require to use reflection.
> The most convenient option from a developer perspective would be a module that > exposes the classes from the bundled jfxrt.jar and doesn't require to use reflection. I am not sure if this is doable - the NetBeans module system can expose APIs of jar files that are inside the NetBeans directory structure, but not for jar files which are dynamically located at the classloader level such as jfxrt.jar. We can not rely on jfxrt.jar being "bundled". Cc'ing Jarda as the module system guru.
Can you explain the reasons for the current architecture in 7.3 dev builds, so it's easier for us to understand what your requirements are? Up to now, when using JavaFX in NB Platform, I create a library wrapper for the jfxrt.jar. That allows me to simply code in a NB Module with all the editor features. (there are additional problems with this approach, but it's a workable solution) What is the reason this can't/shouldn't be done in NB as a prerequisite? Why do you need to load it dynamically at runtime? Is it in order to allow the user to define which JavaFX Runtime should be used, or switch runtimes, etc.? If so, would it be possible to decide on startup wether the module classloader should actually load the jar or not. Then the module would be there (all dependencies of dependent modules satisfied), and the jfxrt.jar would be loaded by the application loader anyway. I'm asking because the main point of an API to me is to simplify seamless development with NB Platform and JavaFX. I wouldn't want to use reflection like in core.browser.webview to add a JFXPanel to my TopComponent. That wouldn't feel like a step forward.
> Up to now, when using JavaFX in NB Platform, I create a library wrapper > for the jfxrt.jar. But that's not sufficient, right? The entire JavaFX runtime still needs to be installed on the disk, as it contains all the system-specific native libraries that are needed to run the application. Don't you still need some mechanism to locate the JavaFX runtime? > If so, would it be possible to decide on startup wether the module classloader > should actually load the jar or not. I defer this question to someone who is more knowledgeable about the NB module system. > I wouldn't want to use reflection like > in core.browser.webview to add a JFXPanel to my TopComponent. I understand and agree that this does not make sense for your usecase. Fo the WebView usecase, the use of reflection is very limited and isolated, so we don't see that as a big problem, especially since it can save a lot on the download size.
There's libs.javafx module which is a wrapper for JavaFX libraries.