We Keep Coding

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.

Without modifying the JRE source code, is there a way to cause the Java VM to only execute local code?

It's my understanding that a lot of the Java VM security issues involve holes in the VM sandboxing mechanism that permit remotely sourced applications to break out and do naughty things to a client machine (not to be confused with a program someone downloads from the web and runs locally - in that case it's up to the user to make sensible choices about what to install and execute). As far as I can tell, the stock JREs available from Oracle are all hard-wired to allow the user to run code from the web. Is there some way to change this behavior? I checked the Java security settings and the 'max' setting still permits the execution of web-sourced code.
I'm asking because I'm working on a desktop application for which I'd like to take advantage of the extensive set of Apache language processing packages currently available. However, given all the security issues with Java, lots of folks are getting rid of it all together, which will hurt our ability to deploy the application to organizations with security policies that prevent Java from being installed on their computers.
So is there a pre-existing solution to this or am I going to have to hack a safer Java VM?

Any Java code that is "run from the web" is launched via the web browser. If you disable Java in the web browser, you've effectively disabled "running from the web".
Java provides instructions for disabling "Java content in the browser" for all browsers at once via the Java control panel, and for disabling it in individual browsers. Hint: This works on both Windows and Mac.
One thing that you may find useful is that the currently recommended way of distributing Java desktop applications on the Mac is to include a full JRE in the application bundle, especially since Java web browser integration is disabled by default on the Mac. This way you're not even dependent on a JRE being installed on the OS.
If only Windows had application bundles, but you may be able to do something similar on Windows. As far as I understand, Java is self-contained in the JRE folders. It's not dependent on other programs or registry entries if you're not expecting browser integration. You should be able to copy a JRE to their hard drive and launch from there.
Locally bundled JREs like this would not be integrated with the operating system, web browsers would not be aware of them, and thus they would not provide the ability to "run from the web".
It's unfortunate that customers are not able to understand this distinction and refuse to install a JRE on the system, which is harmless by itself (with browser integration disabled). Yet, if they find out that you're "installing Java" on their system, you may be out of luck.

How portable is JavaFx 2.0 on the client side of a web application (and is it efficient)?

If I am getting it right from what I am reading, JavaFX 2.0 allows you to code all your logic using Java and design screens with FXML. Then, web apps run as an applet on the client side.
But:
Are all browsers and mobiles devices capable of running applets?
Is it efficient (i.e., nice user experience)?
In other words, how portable are JavaFx 2.0 web applications on the client side? Anyone has experience to share?

From How to run Applets on Android?, it seems like android is not capable of running applets.
So, it seems like JavaFX 2.0 is ok on most browsers, but not for portable devices such as smartphones.

JavaFX produces Java applets. So what I say here applies for Java applets.
Most browsers for desktop machines are Java compatible: IE, Firefox, Chrome, Safari, Opera on Windows, Mac, Linux and Solaris. For smartphones, it seems a lot more complicated. I think it must be a definitive no for iOS, Blackberry and Android. For Windows Phone, it might be possible, but probably too complicated for the mainstream user.
Efficient is a broad idea. It has advantages (performance once started, openess to the rich Java ecosystem) and drawbacks (time to startup, size, all applets running in the same JVM instance). Java 7 improves the experience, as you can read here: http://www.oracle.com/technetwork/articles/java/javaclient-484666.html

JavaFX applications can be packaged in a numerous amount of ways. They can run as applets in a web page, they can be launched through java web start, they can even be distributed as os native applications. So yes, JavaFX is as portable as portable can be. Other people in this thread has already talked about JavaFX applets, which is what governs your question. So I shall not elaborate on that. However, I feel you might have missed the fact that JavaFX clients must not only be distributed as an applet in a browser in order to talk to the back end. Indeed I would not even consider that as an alternative, judging by my own past experience of applets and how ugly they look in the context of a web page.
As an alternative to applets, you can write a JavaFX stand alone application who talks to the back end using a SOAP- or REST based web service. Internet is full of these examples. Moreover, you can have the application be launched through Java Web Start and do dependency injection to get hold of proxy objects to resources on the server. This last part is not talked about by blog posters and Oracle articles. Indeed I haven't found a standardized way of doing that. But if you package a regular Java SE application in a EAR package you can inject resources in this application's Main class and let the thread startup a new JavaFX application and forward those resources. Here is a tutorial I wrote that takes you through the entire process:
http://blog.martinandersson.com/the-enterprise-side-of-javafx-the-missing-part/

JNI + Java Platform + Java-based Application Server + HTTP Web Server

I need to decide between various Java technologies to install on a Linux server.
My back end (biz logic) is a Java program that must communicate with C functions using JNI. This Java program also must communicate with Oracle database (11G) using JDBC on one side, and BlazeDS residing in a Java-based Application Server on the other side (to communicate with Flash plug-in on client side). I also need an HTTP web server.
Not knowing much about Java, I wonder what the highest performance (e.g. fastest) and/or cleanest solution might be.
For example, should I install JDK on the server to provide JNI functionality, then then use Tomcat for everything else? Or, does Tomcat also include JNI? Or would something like JBoss which includes J2EE and serveletts capability be better, since it does everything in one package?
Just trying to learn any conventional wisdom about possible solutions, and pros and cons about going one way versus another.

Any Java runtime environment can do JNI - so by implication if you have any application server (e.g. Tomcat or JBoss) running then you should be able to do JNI just fine.
Tomcat would be perfectly fine for what you are describing.
It's a popular lightweight application server
It supports servlets and JSPs so works well for serving HTML
It's probably a bit simpler to get started with than a full JBoss setup
On the other hand JBoss is great as well.
More of an "Enterprisey" focus - you can optionally get excellent commercial support from Red Hat
Might make sense if you wanted to leverage some of the other products in the JBoss ecosystem
I basically think both would serve your needs. I'd probably suggest writing a simple servlet-based application and try deploying it to both Tomcat and JBoss to see which one you prefer. If you stick to standard servlet features then your app should run on both Tomcat and JBoss so you can keep your options open.
The other thing to consider early is tool support - make sure you get comfortable and happy with your Java IDE tooling for your app development. My personal choice is Eclipse, which has great support via plugins for both JBoss and Tomcat. But most of the other major Java IDEs like IntelliJ IDEA or Netbeans should serve your purposes as well.

G-WAN is an HTTP server (critera #3) which executes Java scripts that can use Jar and other Java classes (criteria #2) while at the same time run C/C++ scripts (criteria #1).
The advantage of this solution is that you will have only one program running (no intermediate layers, no wrappers).
Disclamer: I am involved in the development of this project.

Saving file on disk

In Java, while using Glassfish Server, we could only save files relative to our web application root. Thus you cannot directly save file on eg c:\program files\abc.txt whereas with php this is working. Is it valid? One should not be able to refer any location on hard disk outside web application root (unless you are using Virtual directory). Why are there so contradictory principles?

It's a security feature of Glassfish (via the security features of the JVM). You can disable it if you really want, but the idea is that even if you've got some nasty security exploit in your web app, that shouldn't compromise the rest of the box if it can be stopped.
I don't know whether PHP has such a feature at all - web application containers can do this (and similar things) reasonably easily due to the rest of the sandboxing of Java and the security managers available.

In practical, any deployed applications should not be able to make modification outside its scope because that may allow malicious (or buggy) applications from messing up the hosted server. That being said, it really depends on the application server too, some servers maybe stricter than others. I know for sure Tomcat allows me to write directly to my C drive whereas Websphere server will bark at me if I do so (even though there has to be an option where I can turn it off).

PHP has two such security features. Neither are enabled by default.
open_basedir is a configuration setting that restricts file operations to the specified directory trees. To match how Glassfish is configured, it should be set to the document root in the web server's configuration (using php_admin_value if you're using Apache)
safe_mode is Deprecated (i.e. do not use). It restricts file operations to ones that the user running PHP owns... most likely the account the web server uses.

PHP's older than Java EE containers. It lets you get away with a lot that you can't get away with in newer, less "trusting" systems.