scenebuilder
scenebuilder copied to clipboard
Scene builder does not start unless you try many times to start it
It is working perfectly fine on version 8 but after i've decided to update to recent version this problem occurres and it is really annoying. beside being sluggish it does not even run correctly last time i had to try 10 times like opening from intellij which didn't work then i tried to start it from the shortcut and still didn't work and on the 10th time it starts and it is like the norm situation for i am using jdk 11 and jfx 11 as well
I'm having this issue as well.
How are you starting the ScenenBuilder? Which package have you installed? Are you using the embedded SceneBuilder in IntelliJ?
Thank!
Hi, it's the same behaviour if I start it via the .exe or from the .jar directly, or within intellij.
I have downgraded to Scenebuilder 8 which is working as expected.
How are you starting the ScenenBuilder? Which package have you installed? Are you using the embedded SceneBuilder in IntelliJ?
Thank!
In both cases the stroy is the same in 8th version there is absolutely no problem it runs smoothly (depending on project size) but in newer versions it just doesn't make any sense it doesn't open (i even checked with or without additional libraries which made absolutely no difference).
Hi!
SceneBuilder creates a logfile. Can you please check if the logfile exists share the last lines with the stack trace (if there is one)? Its either the JVM or something in SceneBuilder/JavaFX itself which prevents the start. May be the logfile will help here.
Did you receive any stack traces?
Thanks!
Issue #344 is possibly related.
Could you please check the effective java.library.path
on your system?
This works as follows on a Windows Command Line:
java -XshowSettings:properties
Output is (on my machine):
C:\Program Files\AdoptOpenJDK\jdk-13.0.2.8-hotspot\bin>java -XshowSettings:properties
Property settings:
file.encoding = Cp1252
file.separator = \
java.class.path =
java.class.version = 57.0
java.home = C:\Program Files\AdoptOpenJDK\jdk-13.0.2.8-hotspot
java.io.tmpdir = C:\Users\Username\AppData\Local\Temp\
java.library.path = C:\Program Files\AdoptOpenJDK\jdk-13.0.2.8-hotspot\bin
C:\WINDOWS\Sun\Java\bin
C:\WINDOWS\system32
C:\WINDOWS
C:\Temp
java.runtime.name = OpenJDK Runtime Environment
java.runtime.version = 13.0.2+8
java.specification.name = Java Platform API Specification
[...lot more comes here...]
The problem in #344 is possibly related to selecting the wrong native library version.
It can happen, that the java.library.path
contains more than one path, it can also be multiple JDK bin directories.
In such a case, the first glass.dll
wins, but the first might not be the correct one.
C:\Users\Nick>java -XshowSettings:properties
Property settings:
awt.toolkit = sun.awt.windows.WToolkit
file.encoding = Cp1252
file.encoding.pkg = sun.io
file.separator = \
java.awt.graphicsenv = sun.awt.Win32GraphicsEnvironment
java.awt.printerjob = sun.awt.windows.WPrinterJob
java.class.path = .
java.class.version = 52.0
java.endorsed.dirs = C:\Program Files\Java\jre1.8.0_281\lib\endorsed
java.ext.dirs = C:\Program Files\Java\jre1.8.0_281\lib\ext
C:\WINDOWS\Sun\Java\lib\ext
java.home = C:\Program Files\Java\jre1.8.0_281
java.io.tmpdir = C:\Users\Nick\AppData\Local\Temp\
java.library.path = C:\Program Files (x86)\Common Files\Oracle\Java\javapath
C:\WINDOWS\Sun\Java\bin
C:\WINDOWS\system32
C:\WINDOWS
C:\Program Files (x86)\Common Files\Oracle\Java\javapath
C:\Program Files\Java\jre1.8.0_271\bin
C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64\compiler
C:\Program Files (x86)\VMware\VMware Player\bin\
C:\Program Files\VanDyke Software\Clients\
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0\
C:\Windows\System32\OpenSSH\
C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common
C:\Program Files\NVIDIA Corporation\NVIDIA NvDLISR
C:\Program Files\Git\cmd
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\WINDOWS\System32\WindowsPowerShell\v1.0\
C:\WINDOWS\System32\OpenSSH\
C:\Users\Nick\AppData\Local\Microsoft\WindowsApps
C:\Program Files (x86)\mitmproxy\bin
C:\Users\Nick\AppData\Local\Programs\Microsoft VS Code\bin
.
java.runtime.name = Java(TM) SE Runtime Environment
java.runtime.version = 1.8.0_281-b09
java.specification.name = Java Platform API Specification
java.specification.vendor = Oracle Corporation
java.specification.version = 1.8
This indeed looks also like the java.library.path
. At least for Windows, this is supposed to be no longer an issue with future versions of SceneBuilder. Until then I only can advice to remove JDK 8 and use JDK 16 instead.
What also works is, to install JDK16 as usual upfront and install JDK8 via ZIP file. This will keep the system settings free from JDK8 references and SceneBuilder will work with JDK8 and JDK16 on te same system. This is an ugly workaround but will help until next release will fix this.
This is most likely closed with PR #358. #358 defines a library path only for SceneBuilder and avoids that the system default (Windows path as defined in environment) is used.
Hello @SkrrtNick, @undosimonad & @gigiwest123,
would you be so kind and test the following experimental build of SceneBuilder?
SceneBuilder-16.0.0-SNAPSHOT-issue-362.msi
Here basicalls the packaging process has been updated in order to provide a defined (SceneBuilder-only) library path.
It would be interesting, if this would solve your issues on Windows. As of now, installation of this MSI requires to remove any existing 16.0.0 installations.
Thanks!
Thanks, this is now working.
On Wed, Aug 4, 2021 at 3:56 PM Oliver Löffler @.***> wrote:
Hello @SkrrtNick https://github.com/SkrrtNick, @undosimonad https://github.com/undosimonad & @gigiwest123 https://github.com/gigiwest123,
would you be so kind and test the following experimental build of SceneBuilder?
SceneBuilder-16.0.0-SNAPSHOT-issue-362.msi https://github.com/Oliver-Loeffler/scenebuilder/raw/issue-362-deb-test/testbuilds/SceneBuilder-16.0.0-SNAPSHOT-issue-362.msi
Here basicalls the packaging process has been updated in order to provide a defined (SceneBuilder-only) library path.
It would be interesting, if this would solve your issues on Windows. As of now, installation of this MSI requires to remove any existing 16.0.0 installations.
Thanks!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gluonhq/scenebuilder/issues/342#issuecomment-892728339, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGRZFYGJQVSBU6DMVTQUEJTT3FIJ3ANCNFSM4Z7Q23TA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .
Glad to hear that this works!
@Oliver-Loeffler build works really fine for me. i checked the cfg file in the installation path and figured out the difference was the java-options=-Djava.library.path=runtime\bin;runtime\lib . which is absent by default in the normal scenebuilder build. Caused alot of errors on windows. Thanks @Oliver-Loeffler
@Abdulmaliknurudeen4 Thanks for your feedback.
Eventually this must be solved by versioning of the JavaFX related DLL files on Windows. This is more likely a workaround for SceneBuilder but the issue can occur with other packaged JavaFX applications as well.
As PR #358 has already been merged, this change will become effectively available with Scene Builder 17.
Thanks a ton. Saved me time @Oliver-Loeffler
@AlmasB Hi Almas, please review this issue. I think we can close it as it was most likely been fixed with #358.
Thanks, can always reopen if needed