Can I write client side java in intelliJ, and then simply put it on a server for it to run on a server? Or will I need to write in a specialised version of Java and need to use a specialised IDE instead?
I'm trying to make an app and run the primary functions on a server then have the app send requests and fetch the data from the server. (It will esentially be a search engine of sorts and queries will be made to the server, which will then apply filters and use my algorithms to perform a search, before returning a result to the mobile device). But I'm not sure if I can begin writing this java on intellij, just as I would when making say, a simple calculator, or if I would need to write the java using a specialised server variation and server IDE.
Thank you.
The Java language is the same no matter what, so your logic can be ported easily. However on a server you may use a framework that's different from one you'd use on a client (for example you tagged this android- there wouldn't be Activities or Views on a server. You'd use another framework instead, possibly Spring.) Or you could go frameworkless, but then you'll have to write a lot of code that the frameworks do for you.
As for IDE- an IDE is an editor. You can write Java in notepad if you want. There's no difference, its just what features make your life easier. And yes, IntelliJ is a common choice.
If you would like make your own website, you should go with JavaEE or better with Spring.
If you would like to make simple server side application which will listen on specific port then respond something, go with Sockets
Netty is interesting NIO Socket library
Related
As node.js still lacks important functionality which exists in Java, I would like to use Java instead of node.js, and create the client using a web language (html, js, css..).
Electron is cross platform and so does java so it seems fit to have a solution getting the best of both worlds.
Does someone know of a way to integrate electron with java or have a different solution to the problem?
I made something similar, Java back-end with Electron GUI.
You can do it in more ways, it depends on what you need.
You can create a jar file and then execute it like terminal:
https://nodejs.org/api/child_process.html
Or you can open a socket communication and talk on a Port. (A lot of documentation:
Java (web)socket - Node.js client.io)
In this second way, you can do everything you want, but you have to create your communication protocol.
Your path is not foolish, I am very satisfied of the communication and usage in my work with Java + Electron .
I've created a small PoC where Java process is integrated with Electron front-end: https://github.com/jreznot/electron-java-app There you will find a simple TODO List application built with Vaadin/Jetty and Electron.
Personally i made my back-end java communicate with the front-end by creating a file with te data then sending it to the main.js to be processed.
DBus and winDbus seems to be an option here.
It creates nice abstraction and separation between "frontend" and backend
https://sourceforge.net/projects/windbus/
I'm going to test it on my own soon
I am relatively new to web development, but I have some C++/Java experience. I have got the following conversion to do:
Current:
Desktop Application (Automation Software) developed in C# that communicates with remote PLC (Controller that overlooks different sensors in realtime) using TCP Sockets over the Web.
My Idea:
Convert the application into a server side software that will still communicate with the PLC over TCP/Socket. And use a browser to operate it, so the remote site can be monitored and controlled from any computer in our Intranet (possibly Tablets in the future).
Motive for doing it:
We had a computer fault which left the operators without control.
The new app:
I am planning on writing the server app using Java and OOP (so far no problem). And use HTML/CSS/Javascript for the WebApp and AJAX to update the page.
But I am still lost at how can I transport all this data between them in a proper and decent manner. I have read about SOAP and JSON in this Post. Although, I am not sure if I need to use them at all, is it a good solution to use either JSON or SOAP? Or is there any other solution that you may recommend?
Cheers,
Leo
If you consider skipping the development work to convert your app into a server-side software and just go for a third party solution, I suggest you take a look to Thinfinity VirtualUI.
"...offers a GUI remoting solution for in-house Windows desktop
developments, allowing them to be delivered as Windows/HTML5 dual-platform applications
simply by adding one line of code.
These Windows applications can keep their standard desktop environment behavior and,
alternatively, be accessed remotely from any modern web browser in a multi-user,
multi-instance fashion when hosted on a Thinfinity VirtualUI Server environment."
https://www.cybelesoft.com/docs/thinfinity_virtualui_whitepaper.pdf
SOAP is for defining public APIs that are published on the internet for other people to use, which does not seem like your use case. It is not particularly awesome to have to deal with it from inside a browser either, although there are javascript SOAP-client libraries. There is also going to be a fair bit more overhead on the server side parsing and validating XML than de/serializing between JSON and POJOs.
JSON is much easier to deal with in a browser, being natively understood and all that. Everything you need is built into the core of jQuery, no dependence on plugins that may have unknown levels of future support.
I want to provide a telnet interface to my Java application, primarily so that developers can interact with the app, view debugging information, etc - before we've implemented our full end-user facing GUI.
Can anyone recommend an easy and effective way to do this? I've looked at embedding the scala interpreter, but it doesn't seem to be accessible via telnet. Ditto for Beanshell (which I'm not too keen on anyway as I believe its unmaintained).
Couple of options:
Grizzly for embedding a generic server (http://grizzly.java.net/)
Mina is another similar option (http://mina.apache.org/)
Instead of Telnet, it might be easier to just embed a web server. Not that a CLI isn't cool and all, but it might be a bit easier/more friendly.
Jetty http://docs.codehaus.org/display/JETTY/Embedding+Jetty
Tomcat http://tomcat.apache.org/tomcat-5.5-doc/catalina/docs/api/org/apache/catalina/startup/Embedded.html
JMX is great for monitoring but the UI isn't very good for 'writing' data. NetBeans has some nice tutorial projects in it.
I think of all of the options above the embedded Jetty is probably the easiest.
Have you considered using JMX? It's built right into the jdk and can provide remote access via jconsole to any methods you configure it too.
Now it's not going to work exactly like ssh or telnet, so it might not meet your needs fully. But if your goals is access to invoking methods and debugging information remotely, that's kind of it's main purpose.
The bonus is after you build a UI you can still use the JMX stuff to monitor performance after it's goes live.
Try Jsh its good for telnet related stuff.
I faced this same issue and came up with a slightly ugly combination of nvt4j (telnet server code) plus JLine (Java command line history editor, tab completion, etc.). My application listens on localhost for telnet connections and runs a CLI console loop when it gets a connection.
One key trick is to get the rows and columns information (which is sent via the telnet protocol) transferred from nvt4j to JLine so things don't go haywire when you reach the end of the line.
If you only need a line-mode interface via Telnet, you could use my Java class TelnetStdioRedirector.
So far, I've been searching far and wide on the internet for the best practice when it comes to writing a Java server with a GUI (for stopping and starting it). I know that I have to run the server in a separate thread as the GUI but I was also thinking that it my be a little less complicated if I made each piece, the server and the GUI, in its own Java program or process. If I go with the latter, how do I interact with the server from the GUI if they aren't the same application. Would I just kill the process from Java. I really need some help (or maybe a tutorial).
P.S. I'm going to write the client for other PC's and android phones in the house so I could create a simple messaging system in the network for easy copy and paste between devices so I was considering building the GUI and server in with the client so I could distribute that and it would be two way but I'm not sure if thats the right approach or not.
Thanks!
You sir, are looking for an Application Server, like JBoss. Interact with it using web pages as the GUI. Use HTTP as your messaging protocol (POST and GET). Use Eclipse for Java EE
and read some tutorial / guide. It might be some to learn now, but you'll benefit from it later.
For your requested functionality, create a web application with a servlet for receieving HTTP requests first.
I don't think there is a 'right' way to do this. If as you say, you want to have more than one client (an app running on PCs and an app running on android phones), then you are better off going for a client-server architecture, where your server and your client are two (or more in the case of the different GUIs you want to create) different programs.
The way they can communicate is also open for you to choose. You can go low level and connect through sockets, or you could use HTTP and create web clients.
If you give us a bit more context about what you want to create (server and client are way too generic words) then we could give more tailored questions.
I have a java server with a BlazeDS interface to handle Adobe AIR clients. I also have a bunch of legacy stand alone java apps that I'll need to integrate with the server. The java apps need all the same methods and remote calls that the AIR clients needs. So it would save tons of work if I could call the remote object methods from the java apps.
Anyone know if this can be done?
You can use the BlazeDS Java AMF libraries directly over HTTP. But interacting with the BlazeDS MessageBrokerServlet will require some extra work. Probably an easier path is to just expose the same Java services through another protocol that the Java code can more easily use.
Take a look on this library, it allows you to connect Java with a server running BlazeDS. On the other hand if you are interested in pure performance you can investigate another protocols..there are plenty of them.