Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

importing custom component from javafx 12 or more not working #256

Open
Skyfy16 opened this issue Sep 28, 2019 · 16 comments
Open

importing custom component from javafx 12 or more not working #256

Skyfy16 opened this issue Sep 28, 2019 · 16 comments

Comments

@Skyfy16
Copy link

Skyfy16 commented Sep 28, 2019

custom components from jars files compiled with
jdk 12 or more cant be added to scenebuilder

Capture

@jperedadnr
Copy link
Collaborator

In the title you mentioned JavaFX 12, while in the description you mentioned JDK 12. This is not the same.

Scene Builder 11.0.0 has been compiled with Java 11. Any library compiled with a higher value won't work.

Unless your controls use specific API from Java 12+, I suggest you to set compile your components with source/target level 11.

Also note that JavaFX 12+ can run with Java 11 perfectly fine.

@mkpaz
Copy link

mkpaz commented Dec 25, 2019

Unless your controls use specific API from Java 12+, I suggest you to set compile your components with source/target level 11.

This can be challenging. For instance, I use OpenJFX that bundled into JDK (Liberica). I can't simply use lower compilation level, because it requires including OpenJFX 11 as an external dependency which in turn leads to dependency conflict with OpenJFX bundled modules.

Well, README states that "Gluon Scene Builder is frequently released, and this is only required in case you want to fork and build your local version of Scene Builder." To me it means that Scene Builder should be built with any recent JDK version, otherwise you push users to use outdated JDK just because "JavaFX 12+ can run with Java 11 perfectly fine".

Please, Scene Builder is an essential tool to JavaFX community. You can ignore issues and PRs, but If you can't spare some time just to build it with recent JDK I don't think anything other makes sense.

@GrolarDan
Copy link

I was able to build Scene builder sources with JDK 12 and after that it works.
So why Scene builder can't be released with newest JDK version.
By this date there is already JDK 13 available.

@miho
Copy link

miho commented Jan 6, 2020

Please be aware that JDK 11 is the latest LTS release. Don't expect every Java project to migrate to every JDK release. Many JDK changes in between LTS releases have preview status. That is, they might change in the future. Even if you personally use a newer JDK version this doesn't necessarily mean you have to compile it as JDK 12 or 13 bytecode (e.g. add and/or adjust source- and targetCompatibility in your gradle script).

BTW, if you were able to compile SceneBuilder with a newer JDK, just fork this repository, create a release tag and add the binary as release asset. It's that easy ;)

@johanvos
Copy link
Contributor

johanvos commented Jan 6, 2020

+1 on what Michael said. We use a similar approach for OpenJFX: unless there are very good reasons to leverage 12+ features, we want to make sure OpenJFX and Scene Builder keep working on Java 11.

@TrebuchKill
Copy link

I do not understand the problem from the POV of the SceneBuilder project.

You can run class files, targeting a older runtime under a newer runtime (like classes targeting Java 11 on a Java 14 runtime). Which means the Java 11 release is not required to be rebuild. Assuming the java runtime is up to it, the SceneBuilder, build for Java 11, should work just fine with Java 14 controls. And Java 11 controls should work just fine on a Java 14 runtime (still, SceneBuilder build for Java 11). Re-releasing the SceneBuilder with an updated runtime (like Java 14) shouldn't be a problem, so everyone can use it, be it someone targeting Java 11, Java 14, or Java 8. Or have another option for download: the SceneBuilder as a jar or jmod, for people to create their own runtime images using jlink or jpackage.

You have already instructions for how to run the self-build jar, why not expand on it and release the prebuild jar (for Java 11) without the runtime?

Forcing an upper bound on the target JDK by bundling a runtime, having to compile the project from source and downloading the whole package to get access to the app without the runtime feels unnecessary.

I hope, I am not missing something, but I see a problem, which could have been easily avoided.

@palexdev
Copy link

palexdev commented Oct 11, 2020

Oh wow, now I see why the heck I can't import my custom controls in SceneBuilder
I had to search all over the web to figure out what the issue was

@miho @johanvos from your words nothing emerges but a feeling of laziness.
Plus it's really a shame that this project is supported so badly, there's little to no documentation, and you know, it would be a good idea to show a warning when downloading/installing SceneBuilder because I'm sure many more developers had/are having the same issue without having the slightest idea what the problem might be, and trust me it's damn frustrating.

@HuangLinBao
Copy link

the funny thing about that is that it was working absolutely fine for me when I added the components "fontawesome"...I am having jdk 14 and javaFX 15.0.1 and everything was well....untill I switched to linux I downloaded jfoenix jar file and it worked well but when it comes to fontawesome components nothing happens....nothing added

@treilhes
Copy link

treilhes commented Dec 1, 2020

Hello,

The major problem here is not about compilation source level or the distributed runtime.

The major problem is the fact that most of the submitted issues about SceneBuilder contains "it don't work", a printscreen and nothing else. A log file is needed.

Concerning this issue the right move would be to allow end users to override the java runtime environment using some argument like in eclipse and the -vm arg

@HuangLinBao
Copy link

and how can I have this log file?

beginner here

@treilhes
Copy link

treilhes commented Dec 1, 2020

That's exactly the problem.
In the sources you can find this text in the AboutWindowController

Logging
The default configuration stores logging output in a file named scenebuilder-11.0.0.log (possibly followed by a trailing '.' and a digit).
The default file path is C:\Users<user>\AppData\Local\Temp\scenebuilder-11.0.0.log

But this file does not exist on my computer. the logging configuration was deleted at some point or it was just a bluff

@mkpaz
Copy link

mkpaz commented Dec 1, 2020

If it helps anyone a solution is pretty straightforward. Download latest JDK / JRE of whatever vendor you like and replace (or symlink) runtime folder in the SceneBuilder installation directory. it's pretty obvious that Gluon don't give a damn about SceneBuilder.

$ tree . -L 2
.
├── app
│   ├── icon-linux.png
│   ├── LICENSE
│   ├── scenebuilder-11.0.0-all.jar
│   └── SceneBuilder.cfg
├── libjpackager.so
├── resources
│   └── SceneBuilder.png
├── runtime -> runtime_15
├── runtime_11
│   ├── bin
│   ├── conf
│   ├── include
│   ├── legal
│   ├── lib
│   └── release
├── runtime_15
│   ├── bin
│   ├── conf
│   ├── legal
│   ├── lib
│   ├── LICENSE
│   ├── man
│   ├── readme.txt
│   └── release
├── SceneBuilder
├── SceneBuilder.desktop
└── SceneBuilder.png

@HuangLinBao
Copy link

didn't get the replace thing.....like how??

@UltraBurstXD
Copy link

UltraBurstXD commented Dec 15, 2020

Unless your controls use specific API from Java 12+, I suggest you to set compile your components with source/target level 11.

This can be challenging. For instance, I use OpenJFX that bundled into JDK (Liberica). I can't simply use lower compilation level, because it requires including OpenJFX 11 as an external dependency which in turn leads to dependency conflict with OpenJFX bundled modules.

Well, README states that "Gluon Scene Builder is frequently released, and this is only required in case you want to fork and build your local version of Scene Builder." To me it means that Scene Builder should be built with any recent JDK version, otherwise you push users to use outdated JDK just because "JavaFX 12+ can run with Java 11 perfectly fine".

Please, Scene Builder is an essential tool to JavaFX community. You can ignore issues and PRs, but If you can't spare some time just to build it with recent JDK I don't think anything other makes sense.

That's true, very true. There are many features introduced in non-LTS Java version, and sometimes we might use it's core API to solve some nowadays issues. I use Liberica too because I don't use JavaFX only, there are things it can't do. It's not new programming language, it's just a new GUI framework or library extension... I use everything, and many things are from core API.
I even use, in some cases AWT and Swing to solve my problems alongside with JavaFX...

Not to mention there are many annoying bugs introduced in Java 11, that have been fixed on recent releases. Many things improved, Java 15 is more faster in my tests than 11. I don't have to say the new and improved GC systems and schemes are doing great... I might reconsider using Java in future for my games. It's getting better and better with time.

@UltraBurstXD
Copy link

UltraBurstXD commented Dec 15, 2020

Oh wow, now I see why the heck I can't import my custom controls in SceneBuilder
I had to search all over the web to figure out what the issue was

@miho @johanvos from your words nothing emerges but a feeling of laziness.
Plus it's really a shame that this project is supported so badly, there's little to no documentation, and you know, it would be a good idea to show a warning when downloading/installing SceneBuilder because I'm sure many more developers had/are having the same issue without having the slightest idea what the problem might be, and trust me it's damn frustrating.

No wonder many devs still stick on Swing... JetBrains is making a great progress out there... Jetpack compose may end JavaFX dream... And they have Google support.

Anyway, having an option to choose another JRE or JDK version like an IDE shouldn't solve the problem? Many IDE's or software are built with Java 8 and 11 but have great support for newer releases.

I simply don't understand what's the difficulty...

@johanvos
Copy link
Contributor

We will release a new version soon. Need to fix a few things with signing certificates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests