We Keep Coding

How to specify Java version for Gradle buildSrc?

My build.gradle uses a custom task, which I defined in the buildSrc/src/main/java directory using Java 11. Now, I need to build on a different machine which only has Java 8 installed, so the Gradle build cannot even configure because it complains of errors in my custom task. Of course, I could install Java 11 in my home directory (since I don't have root privileges on this machine) and run Gradle with a custom JAVA_HOME, but is there a way that Gradle could automate this process. That is, could I somehow declare the Java version required for buildSrc so that Gradle will download and use that version?
Gradle toolchains looks somewhat promising, but it is not obvious how this should be applied to buildSrc.

How to fix this version of the Java Runtime only recognizes class file versions up to 52.0 in jbpm

I created a custom process listener for my jbpm and deployed the jar in artifact and built and deployed in project setting and gave deployment.xml resolver type as reflection and package name . classname in identifier
i'm stuck with this error when i try to build and deploy the jar in the project please help me guys.
The error i'm facing

classes with v59 are emitted by javac v15 (or javac v16 and up, if using the --release 15 switch). A java that complains about class files being higher than v52 is java v8.
In other words, you've compiled code to class files targeted at java 15, and are trying to run these on a java 8, and obviously that square peg does not fit into that round hole.
You have 3 available solutions:
Upgrade the java to java15 or up. That'd be the java running in that cloud / workbench thing.
Downgrade the java you're compiling with back down to jdk8. If the class file was e.g. produced on your workmachine, either learn how you configure which java is the default target, or if using an IDE edit the project settings, or if you can't figure any of this out, just uninstall it all and ensure only a java8 is installed. Not recommended.
Configure the build script (and, depending on how you've set things up, your IDE configuration) that you want to target java8. If you're using javac on the command line, this boils down to adding a --release 8 option when compiling. Find the equivalent of that for maven, gradle, eclipse, intellij - whatever you are using.
Any one of these options will fix your problem. The list is exhaustive.

I had the same issue. I was creating the docker image with java 11 version and trying to deploy it with java 11 on Kubernetes using kubectl commands.
How I fixed it: I need to create the docker image again with java 8 version afterthat I moved this image to docker hub and deploy it on Kubernetes.

How do I launch JavaFX program through CMD?

I've created small project using javafx. In Intellij idea it works just fine. But when I build it and tried to run by
java -jar d:\program.jar
in window's command promt it gave me Error: JavaFX runtime components are missing, and are required to run this application.
I've also tried
java -jar d:\program.jar --module-path d:\javafx\lib --add-modules javafx.controls,javafx.fxml
but it didn't work too
Any ideas?

Since Java 11, the JavaFX runtime has been removed from the JDK and it is now its own separate module. This means you need to bundle the requirements for JavaFX in your JAR file (fat jar). Do note that the JavaFX requirements are platform-dependent, which means you'll likely need to create separate JAR files for each platform you're targeting. For Gradle, this will look something like this:
...
def currentOS = DefaultNativePlatform.currentOperatingSystem;
def platform
if (currentOS.isWindows()) {
platform = 'win'
} else if (currentOS.isLinux()) {
platform = 'linux'
} else if (currentOS.isMacOsX()) {
platform = 'mac'
}
dependencies {
implementation "org.openjfx:javafx-base:15.0.1:${platform}"
implementation "org.openjfx:javafx-controls:15.0.1:${platform}"
implementation "org.openjfx:javafx-graphics:15.0.1:${platform}"
implementation "org.openjfx:javafx-fxml:15.0.1:${platform}"
...
}
On the other hand, if you're working with a modular project (Java 9+), you will need to add the required modules when executing the application. For example, in order to run the JAR file (make sure you're using Java 9+, you can check this by running java --version):
java --module-path ${PATH_TO_FX} --add-modules javafx.controls,javafx.graphics,javafx.fxml,javafx.web -jar MyApp.jar
Where the modules that were added using --add-modules argument are the required modules for your specific needs and the ${PATH_TO_FX} variable is the path where the JavaFX runtime can be found.
Do note that this method requires your clients to have the JavaFX runtime 'installed' (and a JRE) on their systems and is generally speaking no longer the recommended way to distribute your Java application.
If you're using Maven or Gradle, there are excellent plugins available to create jlink'ed images that contain your modular project and all dependencies, including a JRE that is optimized for your application and the JavaFX modules. This is, generally speaking, the recommended way to distribute Java 9+ applications to your clients. The plugins in question are:
https://badass-jlink-plugin.beryx.org/releases/latest/
https://maven.apache.org/plugins/maven-jlink-plugin/
This does require that you create a module-info.java file:
https://openjdk.java.net/projects/jigsaw/quick-start

Is there a way to build installers for a java application for multiple targets on the same platform?

I would like to build a .msi, .deb, and .pkg from the same source tree and on the same machine.
Distributable runtimes for Java9+ are no longer downloadable, so perfectly sane solutions like launch4j+nsis no longer work.
javapackager has been abandoned by Oracle.
OpenJDK's jpackager can't (and will never) cross compile for different build projects, and it isn't even a real product yet.
Is there a way to build installers for win/linux/macos from the same machine?
Is the promise of "compile once, run everywhere" is truly dead and buried?
I have a legacy java application that is now in limbo, since MacOS java8 doesn't support java.awt.desktop, which requires java9+

I use since Java 9 and the inception of jlink and jpackage a cross platform setup made of different docker images and Virtual Machines, where I can build the runtimes and the installers (MSI, DEB/RPM and DMG/PKG) on the target platforms within' my host system.
For Mac, you can use a KVM image, if you don't have Apple Hardware, where you can issue commands over ssh.
For Windows, a Linux docker container is used, packed with wine, the OpenJDK for Windows, the Visual Studio build tools, WIX and CMake to perform the build of the runtime image and a customised MSI installer (since the javapackage version is too simple)

The answer to your question is not short. But I'll try to be brief and point to all relevant information.
The short answer is: you can do this.
The longer answer is: you still have to build a runtime for each target environment from within that target environment, but you only have to do this once. You can then save that runtime and reuse it to automatically build installers with your latest Java jars/code in a single environment. For example, use jlink to build the runtime image and jpackage to build the app image for Windows, Linux, and macOS (on those respective systems) then copy those app images to macOS and build an nsis installer (or installer builder of your choice) for each platform from within macOS.
When you update your code and recompile, you can just copy the new jars into the pre-built app image. You'll have to copy in all your dependencies, too, but that would be necessary for any installer. There is a config file in the runtime built by jpackage that has options, classpath, etc., which you can change without a need to rebuild the runtime.
Create a runable program, something as simple as
package com.example;
public class Greeter {
public static void main(String[] args) {
System.out.println("Hi, I'm the greeter. Welcome.");
}
}
compile the program and place in a jar (call it greeter.jar for this example and place in the build directory, called target for this example)
run jilnk to build a runtime. The following command uses jlink from JDK11 and puts the result in a directory called runtime. This example includes all modules on the module path, but you can use jdeps to get just the modules you need. I suggest including all modules if you do not want to ever have to rebuid this runtime when your project evolves and depends on more of the Java runtime. Not to mention transitive dependencies on the JRE.
> set JLINK=C:\Program Files\Java\jdk-11.0.6\bin\jlink.exe
> "%JLINK%" --no-header-files --no-man-pages --compress=2 --strip-debug --add-modules ALL-MODULE-PATH --output runtime
run jpackage to build an app image suitable for packaging in an installer. This uses jpackage from JDK14 early access (the only version of the JDK that has jpackage at the time of this writing). The command line option —win-console is only for Windows and is only necessary if the program does something with stdin/stdout (the console). Our example writes to the console, so we need this. This argument will likely sometimes open a console window when running your application, so remove it if you have a pure windows based (gui) application.
> set JPKG=C:\Program Files\Java\jdk-14-ea\bin\jpackage.exe
> "%JPKG%" --type app-image -i target —win-console -n Greeter --main-class com.example.Greeter --main-jar greeter.jar --runtime-image runtime
run the application with .\Greeter\Greeter.exe
The resulting app image (in the app-image directory) can be used to build an installer with your favorite install builder (I use NSIS). You can do this on any platform. Furthermore, when you update you program you only have to copy your new jars into the app image. There is no need to rebuild the app image or the runtime. This copy of the jars can take place on any platform, and there is no need for Windows to be run in order to build a new installer for a new version of your application.
If your application has jar dependencies (say from Maven central), you’ll need to copy those jars to the Greeter/app directory and update app.classpath in the Greeter/app/Greeter.cfg file. Again, all this can be done on any platform, no need to start up the target platform (Windows in my case).
Also, jpackage is an officially supported tool but only available in EA JDK 14 (it's Feb 2020 as I write). JDK 14 may be downloaded and jpackage can be used with other versions of JDK (like JDK 11 LTS).
See https://blogs.oracle.com/jtc/a-brief-example-using-the-early-access-jpackage-utility
The JEP for jpackage has been marked "Closed/Delivered" suggesting the tool is mature and just waiting for JDK 14 to be released: https://openjdk.java.net/jeps/343
There is an example project on GitHub that has a lot of useful command line examples on how to run jlink and jpackage: https://github.com/jtconnors/SocketClientFX
Though this project uses outdated command options. You can run jpackage --help to get the new options.
Useful Links:
JDK 14 (early access until March 17th, 2020): http://jdk.java.net/14/
Explains non-modular usage of jlink: https://medium.com/azulsystems/using-jlink-to-build-java-runtimes-for-non-modular-applications-9568c5e70ef4
jlink manual: https://docs.oracle.com/javase/9/tools/jlink.htm#JSWOR-GUID-CECAC52B-CFEE-46CB-8166-F17A8E9280E9
jpackage - run with the -help option to get good reference information

Creating a Windows MyApp.exe and MyApp-setup.exe on linux:
I don't need jpackage at all, only jlink, launch4j, and nsis:
Use jlink once natively to create the runtime and tar off the
results for use on other machines.
launch4j can be instructed to use that runtime, and nsis can be
told to copy the whole runtime on install.
Creating a MacOS MyApp.app on linux:
Use jlink to create a tarfile that can be reused to recreate
Contents/runtime/Contents/Home (like for windows above)
Copy in the jpackage generated
Contents/runtime/Contents/Info.plist and
Contents/runtime/Contents/MacOS/libjli.dylib
Copy in the jpackage generated Contents/MacOS/MyApp stub and
Contents/MacOS/libapplauncher.dynand hope they never have to
change.
Create Contents/Info.plist and Contents/app/MyApp.cfg file from
templates using the jpackage generated ones as a reference
Fill in Contents/app, Contents/Resources with my jar files and other resources
Creating a pkg on linux:
https://gist.github.com/msabramo/2a8e44eb6dcc3b89437d33649b0b1841
Creating a dmg on linux:
https://askubuntu.com/questions/1117461/how-do-i-create-a-dmg-file-on-linux-ubuntu-for-macos
Alternately, migrate from nsis to install4j
https://www.ej-technologies.com/products/install4j/overview.html
In theory once I get it all working on linux, I can port the effort to both Darwin and cygwin (WSL just doesn't work right for me atm, will get that working last)
Proof of concept is here (linux, MacOS, cygwin):
https://github.com/nyetwurk/ecuxplot
It is kind of ridiculous this multiplatform crosscompile tooling doesn't exist anywhere, considering the rise of CI/CD, and that the whole point of java is portability and architecture independence.

How Eclipse work with and without JDK?

I have Eclipse for Java installed on my 64-bit Windows 10. And since than, I was able to do Java development without any configuration.
Previously, the automatically build is selected by default. But when I manually delete the .class files, and want to build again, nothing happens.
When I try to run the program, it was not surprised that the error message says that it cannot find the class files.
Notice that, from the beginning, I didn't configure JDK in Eclipse, and it worked.
I found some source on stack overflow that says, Eclipse has its built-in compiler such that it does not need the javac in JDK.
Can I develop Java programs if I have only JRE installed?
But why after I deleted the .class files, the built-in compiler does not work ?

Regarding the JDK: if you are using Eclipse, then you don't need JDK because eclipse has it's own compiler. However for some plugins like Maven to work JDK will be required.
Regarding building the project: Have you tried cleaning and rebuilding the project?
Clean command is available under Project tab.