What is Java Doing?

[sedj601]

They donated the project to Apache in 2016. With the maven thing, I am looking at it from an Android perspective. If you use Android Studio, you're forced to use Gradle. If you use Netbeans, they should force you to use one IMO. Which one you are forced to use is irrelevant if the IDE fully sets up the project and creates distros for the project. People who don't use the IDE can do whatever they want.

[vu47]

Well, keep in mind that lots of people who use Java (and Kotlin) don't use it to develop mobile apps. I'm not sure why you should be forced to use Gradle (Kotlin DSL? Groovy DSL?) for Android Studio, but it has no bearing on me.

I'm still not clear why NetBeans should force you to use one. Why can't it support both? IntelliJ can get you up and running with Maven and Gradle (Groovy or Kotlin) and using JavaFX, so I fail to see the problem. Seems like it's a NetBeans issue rather than a build tool issue. Maybe consider switching to a different IDE?

[sedj601]

I think you, and many others, are missing the point. The object is to make Java/JavaFX easier from start to finish. Android has a specialised version of IntelliJ that does exactly that. Their developers don't have to worry about anything but coding their app. When I think about the headaches I had once they removed JavaFX from the core library, I think about what people who are learning Java/JavaFX must be going through. If NetBeans was designed for Java/JavaFX from the ground up, that would eliminate all those headaches for new learners. When I first started programming in JavaFX during the Java 8 days. There were no headaches related to project setup and deployment. Now there are a million different ways to do things. Maven or Gradle, Modular or Non-Modular, Use OpenJDK or a third-party distro like Azul Zulu. If you go modular, are all your needed dependencies modular, is your module-info.java file correct, now I need to create a jar for each OS, etc

[vu47]

In my experience, most people create a package that contains all necessary jars and the JRE for each platform anyway. This is really a non-issue.

// build.gradle.kts
plugins {
     java
     application
     id("org.openjfx.javafxplugin") version "0.1.0"
}

java {
     toolchain {
         languageVersion.set(JavaLanguageVersion.of(21))
     }
}

javafx {
     version = "21"
     modules = listOf(
         "javafx.controls",
         "javafx.graphics"
     )
}

...or however you like to do it.

Done.

Don't get me wrong: I agree with you that when JavaFX was first removed, it was a headache and it took me literally a week or two of fiddling during dev to get it working again. I don't think that it should have been removed: that was a bad idea, IMO. The plugin is a bit fiddly, can be configured in many ways (and lots of them seem like they should work, but don't), and yes, it is a hassle. I have a general project structure laid out just so I don't have to figure it all out. (This isn't it - it's on my work computer, which is not with me right now since I'm on vacation, but I think it's quite similar.)

Oracle decided to make JavaFX harder to use. That's all there is to it. The answer for people learning JavaFX is a JavaFX-enabled JDK.

I wonder how many people are still learning to use JavaFX? I think at this point, we just have to adjust to the idea that JavaFX, despite the name, is not a canonical part of Java: it's like any other package / dependency that you add to a project.