I have created a JavaFX app, but it seems that servers do not support UI applications. What is the easiest way to develop Java apps for servers? (In other words, what solution does IntelliJ IDEA have? I don't want to rewrite a lot of code)
JavaFX is a technology for creating desktop (client) application on Java. These application are run on a local computer, that computer the user is currently interacting with.
There is Java WebStart technology. It lets us place the application .jar (java executable) on the server and call it via a link from a web page or direct URL. In this case the application will still be running on user's local computer. At the same time, application deployment can be easily managed, since the application executable is sitting on a single location on the server.
JavaFX works with WebStart, you will need to create a JNLP file. It is a descriptor of the application. Here is some info: Java WebStart
I hope this helps.
Java Web App? if I understand you, get my small advice.
You will have to rewrite all controllers, and change UI fxml forms to web pages (html + thymeleaf, jps, jsf and so on).
If you have bad project architecture, for example: you connect with database and retrieve data into controller classes, methods, it's so bad, and you will rewrite a lot of code.
But if it don't
You should just create web controllers, inject needed services, facades and call needed methods there.
Good luck)
Related
I am sure this sounds silly, but for a beginner like me, this is cooking my brain up and I am not able to proceed in my quest without clearing this.
Lets say I am building a simple java command line calculator application that takes 2 numbers and an operator as input and returns the operation's result back to the user. Now, I want to build GUI on top of it (similar to like an online calculator). For this, I decided to build a web application so that I can open the application on my browser and use it seamlessly. It leads to the following questions in my head
Will I have to build a web server in java to allow communications between the front end/GUI and the back end? There is no communication with any other networks, its strictly local; yet I am having to create a web server to make this work and that is confusing me. Or do I need one because I decided to build a web application meant to be opened in a web browser? Or is the reason something else entirely?
If I instead decided to build a windows/android/mac/ios application, would I still to bake a web server for communicating? Or can I use something like swings (I know its really primitive) to do this which essentially would allow the GUI to directly communicate with the business logic?
I know front-end languages like javascript allow me to code the entirety of the calculator in itself, and as a result eliminate the need of a web server. However, what if I was building relatively complex application with a backend database, like spotify? (within the same constraint that the application doesn't need to communicate with other applications and all data is stored locally) Would this solution still work?
In brief, I am failing to understand the purpose of building an entire client-server infrastructure even though the entire thing is local and offline(if that makes sense?). Or is my very basic understanding of client-server flawed?
If you want to use a web browser as the tool to interface with your Java app, then you need a web server. The browser is simply an app that tries to make a network connection with another app, and passes some text as defined by the HTTP protocol.
You would have a choice of three scenarios for this:
Write an app that accepts network connections, processes HTTP, and sends back a response.
Write a Java app that uses the very basic web server built into Java 18 and later. Note that this web server is not intended to be a feature-rich or commercial-grade server.
Write a Jakarta Servlet class that runs on top of a Servlet container with a web server. For your needs, either Apache Tomcat or Eclipse Jetty would work well as both the Servlet container and the web server.
For your scenario, the middle option using Java JEP 408 seems most appropriate and easiest.
You said:
There is no communication with any other networks, its strictly local; yet I am having to create a web server to make this work and that is confusing me.
A Border Collie dog herds sheep. That is its most basic basic core mission. Those sheep can be herded across the hills of a mountain range or they can be herded locally within your own farm.
A web browser makes network connections. That is its most basic core mission. Those network connections can be made over the actual network or they can be made locally within a single computer ( a “localhost”).
You said:
Or do I need one because I decided to build a web application meant to be opened in a web browser?
Yes a web application accessed by a web browser needs a web server, by definition.
You said:
If I instead decided to build a windows/android/mac/ios application, would I still to bake a web server for communicating?
Or can I use something like swings (I know its really primitive)
There is nothing “primitive” about Swing. It is a fully-developed feature-rich GUI framework. Swing comes built in with every JDK. And Swing will be supported for many years to come.
However, the design and features of Swing may or may not suit your tastes. And Swing is now in maintenance-mode.
An alternative is JavaFX, now actively developed as the OpenJFX libraries.
To use JavaFX, you must either add the OpenJFX libraries to your project or else deploy to a JDK that comes bundled with the OpenJFX libraries (ZuluFX, LibericaFX, etc.).
to do this which essentially would allow the GUI to directly communicate with the business logic?
Yes the GUI and and your calculator business logic would all be plain Java classes, all peers, all running together within the same JVM.
You said:
I know front-end languages like javascript allow me to code the entirety of the calculator in itself, and as a result eliminate the need of a web server.
Yes. You could cook up JavaScript code to implement your little calculator. This JavaScript could be placed within the text of a file with the HTML of a web page. That web page file could be opened locally by the web browser. Your HTML and JavaScript would render. No web server is needed in this scenario.
But this scenario eliminates Java, and you said you want to (a) write your calculator in Java, and () use a web browser. So we go back to the three options listed above.
You said:
However, what if I was building relatively complex application with a backend database, like spotify? (within the same constraint that the application doesn't need to communicate with other applications and all data is stored locally) Would this solution still work?
Yes you could deploy a database server on your local machine. Then you could find and use a JavaScript binding tool to talk to that database.
But then you would not be using Java and all its goodness. For that scenario I would choose to write a JavaFX app with an embedded Java-based database engine such as H2. This would result in a single all-in-one double-clickable-app solution.
But that would be my choice based on my own preferences and skill set. Other people might choose other solutions.
the purpose of building an entire client-server infrastructure even though the entire thing is local and offline
👉 The “offline” part may be distracting you.
Conventional computers with modern operating systems such as macOS, BSD, Linux, Windows, etc. are always “online” in that they all maintain a networking stack. That network stack can be used locally by processes within the one computer to communicate with each other. Whether you happen to have an Ethernet cable plugged in, or WiFi turned on, makes little difference to the computer. The networking stack in the OS is still available and active regardless of outside network access.
So client-server architecture works just as well within a single computer as it does between computers. (Actually, it’s works faster locally, as hopping on and off the network is terribly slow.)
Why choose client-server architecture for a local app? Either:
You are skilled in, and prefer, the tools for a client-server architecture.
You want to eventually move from local-only to being networked.
If neither of those two is true, then the JavaFX with H2 solution I mentioned is likely a better fit for a Java programmer.
By the way, let me put in a plug for Vaadin Flow, a GUI framework for building web apps in pure Java.
It's not completely necessary to bake web server to host your application even with embedded tomcat application you can host your application. However, main purpose of webserver usage is for setting up your reverse proxy so that your application behind that won't be exposed and your webserver will be acting as endpoint to outside requests.
In case for hosting application in local webserver is not at all required webserver will come handy when your application hosted in production environment.
I have a standard java project working local made by another person i know.
It's about data retrieving.
I need to develop a web app supposed to do the same thing but accessible by anyone via browser.
I CAN'T edit the code for that purpose, at least some implementation details. A kind of black box.
Can you suggest me the best approach to make a webapp based on a local executable app through JSP & servlet ecc?
Maybe you can try something like webswing.
What is Webswing ? Webswing is a web server that allows to run any swing application inside your web browser using only pure HTML5.
The best days of swing framework are gone. Desktop applications lost
popularity and everything is forced to be online and mobile. But what
about existing application? Using applet technology proved to be
insecure, rewriting the application to web technology is too
expensive. This is where Webswing can help you. With Webswing, your
application is securely running on server and user's browser only
displays the application window. All this without changing single line
of source code.
I am trying to understand what are the use cases for using Java Web start. What are the advantages of it over a web application. Is Java web start still relevant today?
What are the advantages of Java WebStart over a web application
These two are very different approaches to implement an application:
A Web Application typically refers to an application which runs completely on the server side (keeping aside JavaScript, which executes inside the browser) and uses a web browser to visualize its user interface and handle user inputs. The main advantage of such an application is that no software needs to be installed on the client side, besides the browser (which is usually available on any system today). Sometimes this is referred to as "zero-deployment".
Java WebStart on the other hand is a deployment technology which allows to download applications and run them locally on the client. The starting point is again the everywhere-available browser (or more specifically a URL), but once clicked, the URL downloads binary components (.jar files, but also system dependent native binaries) to the local system and then they are run locally. This also requires a very low effort from deployment perspective, but at least a Java Runtime environment needs to be available locally. But still, it is much less effort to run an application than having to download a installer, launch the installer, choose an installation directory etc. Java WebStart does that for you. Additionally, it also automatically handles updates - when the url is clicked subsequently, WebStart checks if the files have changed since the last run and downloads them as necessary. Otherwise, it uses the files from a local cache.
Is Java web start still relevant today?
Yes, definitely. If you have a rich (Java) application which needs to run locally on the client, you can use WebStart to deploy it with very low effort - all you need to send to the users is a URL.
See also
https://stackoverflow.com/tags/java-web-start/info
Is it possible to use Java webstart execute .exe or dll?
Java Web Start and Web applications solve two very different problems. A Web Start program is a regular graphical application program that is downloaded to and run on the user's computer. It acts like any other downloaded program written in Java, and typically uses a toolkit like Swing for its interface. It'll need to be digitally signed and approved by the user, and the user will have to have a JRE installed on the client computer. Web Start is just a convenient way to get the jars for the application downloaded and kept up to date. Web Start is useful for applications that need quick response times, lots of computation, or to access files on the user's computer (e.g., a photo uploader).
Web applications, on the other hand, are Web sites with interactive features. Examples include everything from Google's search suggestions to Facebook to Stack Exchange. Java is a useful language to write Web applications in, with tools like Spring and Hibernate, but a Web application is just a Web site that's delivered to the user as HTML and Javascript and runs in a Web browser.
I have a Java desktop app (with a Swing GUI) that runs in a LAN environment. Normally, I run it with a bunch of machines, some play the role of servers while others act as clients.
Now, I would like to run the same app on the Internet, where both the server and clients will be hosted on a website, so that visitors of the website will be able to run as the clients and interact with each other.
I wonder what are options are available for such migration? Do I need to re-write everything from scratch using some Java-based web framework? If so, how should I deal with the GUI part? Or do I just host the app as an applet? (somehow I am reluctant to go down the applet route, as it may require additional setup on individual visitor's machine I have no control of and there may exist compatibility issues). Thanks!
One option would be to use Vaadin. The programming mindset is quite close to JavaSE Swing. It is a GWT derivative on the client-side, but the logic is really on the server JVM and the framework takes care of the communication (xhr or web sockets).
Google Web Toolkit (GWT) could be usefull for that since it will let you re-use generic Java code and compile it to JavaScript for running in the browser. In my app I am reusing classes in the client that I use in the server. The UI has to be recreated using web widgets though however wysiwyg tools exist for that.
You could also migrate your raw sockets to Websockets if you require bi-directional communication.
If your code follows the mvc pattern it should be possible to reuse the model stuff. My favorite java web frameworks are those from spring source. Spring mvc (clean mvc design) or spring roo (more the rails style with code generation etc.). Both integrate well with the dojo framework (ajax / gui stuff).
I work on a standalone Java application that is a command-and-control system for an assortment of hardware. The C&C software basically runs from a command line, and controls the system hardware which is spread out all over the place. It does not require a GUI to meet the business requirements. I have written a small swing GUI just so I can see what the overall status is of the system, but again, that is not essential.
Going forward, we would like to have a Administrative web GUI with system status and something that would give a user some level of control over the hardware. We were thinking that GWT might be a viable solution. Our GWT app would have to have some sort of IPC with the C&C software. I don't know how viable that is, I don't know that we want the C&C software bundled as a web app that has to run under application server.
I just don't have much experience with this. I was thinking that the GWT client would interact through RPC with the GWT server, and the GWT server would have some sort of RPC (RMI???) with the C&C.
Another option you have is to run a Java Applet that can interact with both GWT (using JSNI) and with the OS. A simple example would be to open a common file in the user's home folder and read/write to that file (with the C&C app doing the same as well).
You can embed embedded tomcat or Jetty into your application and let it run a simple servlet/JSP - based or GWT-based web UI. In fact, when you debug/run your GWT application from Eclipse, it starts in an embedded Tomcat instance.
I found a solution by using Spring. We have modified much of our Command and Control app to use Spring IoC, and then we used other Spring libraries to extend its functionality. To interact with GWT, we exposed services and used httpInvokers to make calls from the GWT server code.
Of course, this meant we needed to use Spring with our GWT application too in order to make the http calls from the GWT server code. But all is working.
you dont have direct control on the client system with JavaScript (which GWT is based on). in your use-case that wouldn't even make sense, why using an external server for a website controlling a local program?
If you reverse this (the app server is running on the same system as the C&C software, and the web client is available from everywhere) than that would be possible, but that wouldn't have much to do with GWT. On the server you can write normal java code. GWT just would be used for the web GUI and the RPC-calls to the server.
The call to the C&C software from the app server could be realised with the following line (windows example):
Runtime.getRuntime().exec("C:\\PathTo\\Program.exe")
This function return a instance of class Process which provides an Input- and OutputStream to simulate user input and to read and process the programs output.
Please note that you lose platform independence with this method, because the parameter for exec() looks different for every OS.
EDIT
After re-reading your question, it would even make more sense to integrate the C&C software into the server code directly, as the comment on your question suggests. you need a application server to use GWT-RPC, not a webserver, but thats hairsplitting.
Informations on how GWT-RPC generally works can be found here: (tutorial), (detailed description)