Develop Reference

Is it still realistic to deploy a JavaFX application using Maven in a Web Browser

I read here that it's possible to deploy a JavaFX application into a Web Browser:
embed-a-javafx-application-in-a-html-webpage
Now I got stuck at the beginning when he talks about using the java packager to create an executable .jar file. I'm using Maven which uses JavaFX 18, so I followed this tutorial on how to package a java project
java-packager-with-jdk11
Here I got confused with the tools he uses. I downloaded the listed tools and moved the jpackager files into the according directories. Still in cmd it gives me an "Error during initialization of boot layer": jdk.packager not found.
It's pretty worth it knowing how to create a Package from a Java Project, but is this the proper way?

tl;dr
No, not realistic.
You have a choice of alternatives.
Legacy technologies
That page uses legacy technologies, Java Web Start and Java applets.
Java applets have been phased out by all web browser makers, so Oracle consequently decided to phase out the technology. Java applets were first deprecated in Java 9, and later deprecated for removal in Java 17.
Oracle no longer expects end-users to have a standalone JRE or JDK installed on their computer. So Java Web Start is no longer available by default for the consumer market. Java Web Start is no longer included in Java 11+.
However, an open-source implementation continues in the OpenWebStart project. For some environments, such as corporations or schools where the installed base of computers is centrally managed, OpenWebStart may be a useful way to distribute apps.
Ship your app with JVM bundled
Oracle now expects desktop apps and mobile apps to bundle a JVM within their product. This does mean the app must be built in editions, one edition for each supported chip architecture and OS, but also allows the app to be tested with the same JVM that will eventually run the app.
For more info, see the Oracle white paper (PDF format), Java Client Roadmap Update of 2020-05.
New tooling is available to support this JVM-within-app packaging:
Java Platform Module System (JPMS) in Java 9+.
jlink in Java 9+.
jpackage in Java 16+.
Search Stack Overflow to learn more about packaging JavaFX/OpenJFX apps for distribution. Many Questions and Answers have already been posted on the topic. The topic is rapidly evolving, including cutting-edge approaches such as using GraalVM for ahead-of-time compilation to run native.
Vaadin Flow
If you want to build a single-page web app written in pure Java without you needing to learn HTTP, HTML, CSS, JavaScript, WebSockets, Push, etc., consider using Vaadin Flow. This open-source framework is based on venerable Jakarta Servlet technology.
You write Java code similar to that in JavaFX, defining forms by specifying widgets arranged with layout managers. Vaadin Flow then auto-generates the needed HTML+CSS+JavaScript to render the user interface remotely in the web browser while maintaining the state of your app on the server. Pure Java on server, no Java on client.

How to deploy Java Swing Application on Web Browser?

I've found exactly the same question I just made but it is 7 years old; so I'd like to have an "updated" answer if it is possible. Thanks.

Old days
As commented by TrogDor, there were previously two ways to deploy a Swing app through the web:
Java Applet technologyYour app would appear within a rectangle on the web page, within the browser.
Java Web Start technologyClicking a link on a web page would download a copy of your Swing app to the user’s local machine, where your app would then be launched locally using a locally-installed JVM. So your app runs separate from the web browser. This click-to-download-and-run process is defined by Java Network Launching Protocol (JNLP).
Both of these are being phased out.
➥ For details, see the white paper Java Client Roadmap Update published by Oracle, updated 2020-05-11.
Nowadays
The modern approach is to build a Swing and/or JavaFX app, then deploy by using a packaging tool to include a JVM. You end up with a complete self-contained self-launchable application.
This means you need multiple builds, one app for each platform your users may deploy on (macOS, Linux, BSD, Windows, and so on). While that is an additional burden to you, the flip-side is that you control exactly what version of Java is being used to run your app.
Because of the Java Platform Module System (JSR 376) in Java 9 and later, you can now strip down the bundled JVM and libraries to include only the parts actually used by your particular app.
The build tools for packaging your app have been rapidly evolving in recent years. So be sure to do your research to find the most robust and modern tooling.
Alternatives
You might consider any of these alternatives:
Remote execution
OpenWebStart A re-implementation of Java Web Start
GraalVM Ahead-of-time native-code compilation of your Java app
Vaadin Flow Using Java to build desktop-style apps delivered as web apps
Remote executions
Some vendors may offer a product or service to execute your Swing app remotely while displaying the user-interface within a web browser.
One such company is WEBSWING Ltd. with their Webswing product.
OpenWebStart
You might be interested in a separate implementation of Java Web Start technology.
While Oracle is phasing out Java Web Start, there is an open-source implementation of JSR 56: Java Network Launching Protocol and API called OpenWebStart. See GitHub. This project is currently maintained by the company Karakun, based on the IcedTea-Web core functionality developed at Adoptium (née AdoptOpenJDK).
GraalVM
A cutting-edge alternative is to build an entirely native-code ahead-of-time compiled version of your app using GraalVM.
Vaadin Flow
An entirely different way to build a web app by using Java is the Vaadin Flow framework.
You specify your user-interface layouts with widgets in a manner quite similar to Swing, specifying an arrangement of widgets (buttons, fields, labels, etc.). You can do so using your choice of straight Java code, an XML-based description language, or a visual design tool.
At run-time, Vaadin automatically automatically generates the HTML, CSS, and JavaScript necessary to render your app remotely on the client user’s machine within a web browser. So, you have pure Java on the server-side, and no Java on the client-side, just Web standards technologies built into all modern browsers.
More info
All of this has been covered many times already on Stack Overflow. So search to learn more.
For tips on obtaining a JVM to bundle with your app, see How to get java 11 run-time environment working since there is no more jre 11 for download?.

Nowadays you can run Swing app on server with UI in the browser. You can find example here: https://github.com/JetBrains/projector-demo.
Update: JetBrains ceased development of Projector as a separate product. See their notice. They have incorporated the technology for their own use in their Gateway product for remote execution of their IDE products.

How we can deploy Desktop application to clients, for Java 11?

Previously, this is how we deploy legacy desktop application (https://jstock.org, written in Swing and JavaFX) to clients.
Developed in Swing and JavaFX
Use NetBeans as IDE
Use Java 8
Use Oracle JDK
Use Launch4J to create EXE
Use NSIS to create installer, will help user automatically download JRE from http://javadl.oracle.com/webapps/download/AutoDL?BundleId=216434
Due to the complex licensing requirement introduced by Oracle, we want to move away from Oracle, and go for Amazon Corretto or AdoptOpenJDK or Azul or whatever is free.
We want to take this opportunity to migrate to Java 11. But, we notice that there are no JRE for Java 11.
After some research, we though we might need "Self-Contained Application Packaging" technology, to deploy our Desktop app solution to clients, if we were to use
Developed in Swing and JavaFX
Use NetBeans as IDE
Use Java 11
Use Amazon Corretto or AdoptOpenJDK or whatever is free
The information we came across is https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html#A1307236 . But, it is pretty brief, and we still don't know how we can apply "Self-Contained Application Packaging" for our case?
Do you come across any good tutorial resource, to deploy Java 11 desktop app?

Is it possible to invoke a .NET Core app in Java?

I have a .NET Core (console) app that I would like for a Java app to depend on. Essentially I would like to be able for the Java app to invoke a multi variable method in the .NET Core app and then pass the result back to the Java app. It would be nice if the .NET Core app could be embedded in the Java app. I have previously seen .NET Framework specific solutions to this problem, but since this would only be relevant on Windows, I would like a solution that also works on Linux.

In the past there were some technologies such as IKVM.NET and COM Interop wrappers but the former is defunct and the latter probably wouldn't work on Linux.
Since you own the .net core code, I would take a more modern microservice approach. I would design the .net core app to be a REST API running as a console app listening on a port. I'd have the Java application spin up the console app, invoke the methods passing JSON back and forth and then spit it down when complete.

From my actual knowledge this nuget package JCOBridge is able to do what you are asking for.
Until now it supports linux for x64 architecture.
I tried the templates available on Templates and them works on my Ubuntu 18.04. The same templates works on Windows.

.Net vs Java for mobile development. What's your take?

I am developing mobile apps for some time in .NET and I was always wondering if the grass is greener on the other side (Java).
Thus, I would like to ask your opinion about which one you prefer for your mobile apps and why is that so.

The main advantage of using Java is the broader installed base. If you use Java, you are going to reach orders of magnitude more phones than if you use .NET.
As far as I know, .NET works exclusively with Windows Mobile phones.
On the other hand, Mobile .NET is easier than Java (IMHO), and that's partly because of Visual Studio IDE which makes life so much simpler than any other development environment on the Java World. For example, doing Form Based applications in .NET mobile is really straightforward and simple.
So, the answer will basically depend on what you are trying to accomplish:
Trying to reach to the biggest number of mobile devices: go with Java
Trying to develop an application for Windows Mobile devices: go with .NET
Trying to develop an application that will run only on a controlled environment (A single business) where you get to decide the devices it will run on: decide which device you are going to use and then pick development environment.
Keep in mind that if you are talking about Java for Android or Blackberry development, you will face the same issue of not reaching to a huge installed base that you will with .NET. If you want the huge installed base, go with plain Java Mobile Edition.

I can only speak for windows mobile development stay with .net.
Sun don't even release a JVM for windows mobile devices I have developed for windows devices using java and using http://www2s.biglobe.ne.jp/~dat/java/project/jvm/index_en.html as my JVM which was very good the author even responded to a feature request I made.

It is true that if you're going to develop for WindowsMobile, J2ME is not a very good option. More than likely your device of choice will not come with a JVM and if it does, it'll be buggy and slow. Also, forget about trying to integrate with with OS at more than a basic level.
Just to add to what others have said, Sun has made phoneME available and if you want to go that route and deploy your MIDlet and VM together that is certainly a possibility. It's just a lot of work at this point.

For .NET guys - there is a Ubiq Mobile framework. Ubiq Mobile apps work on Android, iOS, Windows Phone and Java-based phones and tablets. This is rapid cross-platform development with .NET with cloud-based architecture. Getting started article: How to create simple UbiqMobile application with video.