We Keep Coding

Creating a webapp using JavaFX - is it possible?

I'm making a database for my project (wirtual clinic) which will be a web application, but here is a thing.. I want in order that my app will based on a JavaFX (MVC pattern, where in View segment I could use .fxml files edited in SceneBuilder) is this solution possible?

If you need a web application running in a browser with a backend in a container, then you cannot use JavaFX. But you might try Vaadin. There you can use either Java code or HTML to build your application. They also sell a designer application.

The http://javafx-samples.com/ mentioned in the other answer shows a JavaFX application running as a server process and mirrored thru the network using JavaScript. This is technically admirable and might work reasonably well for your use case but you should keep that in mind when comparing it to client side JavaScript solutions.
It will not work well for flaky internet connections and extending it will have limits since it would require both Java server side code and JavaScript side code.
Such architectures have been used extensively in the past (e.g. Echo2, AjaxSwing etc.) and they all never gained serious traction even when compared to similar architectures such as GWT.
There are now several client side JavaScript based VM's including TeaVM which are pretty amazing and can produce pretty good results entirely on the client e.g. we used this VM in a recent demo.

Of course it is possible, but with the plugin and updates problems.
Some solutions are in progress. You can check this site:
http://javafx-samples.com/
It is promising I think because you don't need plugin.

Standard Java webapp with optional Google App Engine support

I've built plenty of Java webapps that run in standard containers like Tomcat and Jetty, but I've never built one that runs in Google's App Engine before. I'm using Maven, so I had originally thought that I could just do this with build profiles to just optionally include Google's libraries at build time to make an App Engine-compatible WAR.
Unfortunately, it seems to be more complex than that. In reading through the documentation, there seems to be an awful lot of very specific code you have to write in order to use the App Engine. For example, all file system writes need to go through the App Engine data store, so you can't use native java.io.* libraries.
I understand why these things are necessary, and I wouldn't mind having some of this code in my webapp. However, I really don't like the idea that my webapp can only run on the App Engine. Is it possible/feasible to write my code in such a way that I can also run it in a typical container like Tomcat?

It mostly depends on what you app is going to do. You are going to run into troubles as soon as you want to do stuff with the datastore, or caching for example. Perhaps you could wrap things line datastore calls or caching, but certain apis, like search you can forget about. If you just want to run something locally that is no problem you can mock the app engine locally.

Which option is suitable to replace Java Applet?

I would like to replace Java Applet which currently needs to use client's resources, i.e. external readers, and to communicate with a server via socket.
Reason:
1. I have thousands of client machines using this Java Applet program, and most of them are running out-dated JRE. When the Java Applet program is updated / added new features, all client machines will need updating the latest JRE.
Expected Solution:
The Java Applet program would be expected to be replaced by a web-based application, which allows to compile and run source code at client's side such that the new web-based application could still use client's resources and communicate with server via socket.
Can I use JavaScript to achieve it?
I would very appreciate your help/suggestion for this problem. Thank you!

JavaScript is a scripting language that gets evaluated in the browser.
I would not describe it as compiling and running but yes, it does mean you can run code in the client and is commonly used to create applications that run in the browser.
There's a staggering amount of frameworks that you can use to write your application. Take a look at the TodoMVC site to see the same TODO app created using several different frameworks.
If you come from Java applets, GWT may be interesting to look at.
If you wish to let the JavaScript client listen for messages from the server, take a look at websockets.
The smart card reader is going to be a problem, though!
See Architectures to access Smart Card from a generic browser? Or: How to bridge the gap from browser to PC/SC stack?
By the way:
The real issue with outdated JREs is not that your code will not run on old JREs, you can create perfectly fine applets using java 1.4 or java 5. Any libraries you may need you can deploy alongside your applet. The pain is a security problem. Anything but the latest version Java plugin is getting actively exploited and puts the user at risk. Occasionally, even the latest version is not safe.

try socket.io
I think this is the latest technology you can use to communicate with client browsers. it support the latest browsers and mobile browsers too.
hope this will help you.

Javascript has become very powerful with HTML 5.0. Here is a list of new elements that you can use to access all kinds of resources, including local files, audio, video, GPU rendering (canvas + WebGL) and GPU compute (WebCL). Here are even more things you can do, including database connections and networking. You can even create offline Javascript applications.
jQuery and jQuery layout make robust GUI development a lot easier. Rich tool suites, such as Google Closure offer optimization and a compiler for improving performance and detecting obvious mistakes early in the development process.
W3 offers useful stats for making an informed decision on how many users on average have access to which features. Note that the most annoying guy in that list arguably is IE8 due to it's lack of proper HTML 5.0 support.

In case you want to stick with Java, then one alternative would be to use my http://bck2brwsr.apidesign.org project. It's goal is to create small Java that can run in 100% of modern browsers without any plugin installed.
There are Java bindings to HTML (via knockout - one of the four most popular frameworks for HTML5) and that is why one can code whole business logic in Java and just render it via HTML. Should be enough to replace most of the applet UI.
In addition to that there is an experimental API to render on HTML canvas. People use it to write Java games that run in a pure browser.
There is a simple way to communicate with server via JSON REST API or via WebSockets. A live example is here.

GAE: Python and Java services together under same App ID

I have some Python services and I have defined handler locations for them in app.yaml
I also have Java services and I have configured web.xml.
I want them both to be under same APP ID, e.g.
The Python app would be in http://myapp.appspot.com/pythonapp
The Java app would be in http://myapp.appspot.com/javaapp
So how can I accomplish this?
When I use GAE Java Eclipse plugin, it only uploads the Java service and deletes existing Python service.
When I use appcfg.py update it only uploads Python service and deletes existing Java service.

There is a hack: upload to different versions
You can have one instance version in Java and the other in Python. The default one will be visible to public via http://myapp.appspot.com.
You can access the other version (in browser or programmatically) viahttp://version.myapp.appspot.com, e.g. http://3.myapp.appspot.com
If you wan to acces both of them via the same URL, then you will need to proxy the request or do a redirect (if your client allows it).

There is no official way to use two runtime environments with one app. Jython is one way to run Python code in the Java runtime environment.
Depending on your needs, you can try using two different app versions with the same app ID. One version can use the Java runtime environment, and the other can use the Python runtime environment. Both versions would see the same datastore. You can address each app version separately using appspot.com URLs, though they're not pretty: http://version-id.latest.app-id.appspot.com Only one version can be the "default" version (http://myapp.appspot.com). This uses 2 of your 10 allowed versions, and you'll have to be careful to deploy each version with the correct version IDs. So it's not an ideal solution.

I'm sure that you can have only one app at same time, because it's different app servers/VMs for each type. I mean you can't upload different parts, can't have different sdk for different url on same app, etc.
Btw, you can try to use jython, it can interpret your Pythong code in Java project. I'm not sure that it's production ready (there was a lot of problems with it when i had tried it few years ago), but maybe it's helpful for your situation

As #splix said, deploying two app with different languages into the same appid seems to be impossible. So how about a workaround instead? Set a /pythonapp servlet on your Java app that will redirect all requests to mypythonapp.appspot.com via URLFetch.
The drawback of this workaround that come into my mind is that you are losing the information about the logged in user provided by the User API, so you would need to attach the information on the redirected request. Depending on the scenario of your app, I don't know whether this would be a show stopper or not.
EDIT: What I had in mind is what Peter suggested, using different versions rather than deploying them as totally different app, sorry that I mixed them up. Deployment to a different app would mean your Python app and Java app could not use a shared datastore.
The difference on my answer is that you could use URLFetches to forward the requests between different versions of your app. But having the redirection performed on the client's side as per Peter's suggestion rather than having it done on the server side as in my answer would probably be less hacky.

GWT interaction with external standalone application

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)