We Keep Coding

Exporting as stand alone application

I exported Processing application as a standalone application with embedded Java, but the exe does not work in computers where Java/Processing is not installed. Even if the Windows 64 bits works with Java embedded, the 32 bits does not work with Java embedded or not. The computers that do not have Java already installed open the Windows 64 bits exe but not the Windows 32 exe (with java embedded in its exporting process). Here's the post in Processing forum: https://forum.processing.org/two/discussion/25373/no-export#latest
Can it be resolved? Thanks.

You can only include the Java version for the type of machine you're running on.
If you're on a 64-bit Windows machine, then you can only include Java in the 64-bit Windows application. If you're on a 32-bit Linux machine, then you can only include Java in the 32-bit Linux application.
If you really want to include Java for a bunch of different machines, then your best bet is to find each type of machine and do the export from them. Find a 32-bit Windows machine and do the export there, then find a 64-bit Linux machine and do the export there, etc.
You might be able to hack something together by downloading the JRE for each type of machine and manually including it, but that might get pretty tricky. Note that this is not as simple as just copying a folder into your application directory. You're going to have to change the run script file as well.
Shameless self-promotion: I've written a tutorial on exporting applications from Processing available here.

What is the difference between Java components (JRE, JDK, JVM, JIT, and javac)?

I've had a hard time while understanding the difference between JVM(Java virtual machine), JRE (Java Runtime Environment), JDK (Java Development Kit), JIT (Just In Time Compiler), and javac (Java compiler).
What is a good comparison and contrast between all of these?

You might have done so much of google to find the answer of this question and came across a very boring diagram showing the architecture and interrelation between JVM, JRE and JVM. It took me almost a year to understand it practically (not theoretically).
Let’s find out the answer of this simple (but yet very important) question:
What is JDK, JRE and JVM?
JDK:- Java Development Kit (in short JDK) is Kit which provides the environment to Develop and execute(run ) the Java program. For eg. You(as Java Developer) are developing an accounting application on your machine, so what do you going to need into your machine to develop and run this desktop app? You are going to need J-D-K for that purpose for this you just need to go to official website of sun or oracle to download the latest version of JDK into your machine.
Hence, JDK is a kit(or package) which includes two things i) Development Tools(to provide an environment to develop your java programs) and ii) JRE (to execute your java program). JDK is only used by Java Developers.
JRE :- Java Runtime Environment (to say JRE) is an installation package which provides environment to only run(not develop) the java program(or application)onto your machine. For eg(continuing with the same example) after developing your accounting application , you want to run this application into your client’s machine . Now in this case your client only need to run your application into his/her machine so your client should install JRE in-order to run your application into his machine.
Hence, JRE is only used by them who only wants to run the Java Programs i.e. end users of your system.
JVM :- Java Virtual machine(JVM) is a very important part of both JDK and JRE because it is contained or inbuilt in both. Whatever java program you run using JRE or JDK goes into JVM and JVM is responsible to execute the java program line by line hence it is also known as interpreter(we will discuss about interpreter later) . Hence you don’t need to install JVM separately into your machine because it is inbuilt into your JDK or JRE installation package. We’ll explore more about JVM soon.
Finally after learning about all the three main parts of java you can have a look at the above figure to have clear understanding of the architecture and interrelationship between all the main components of java.

Well, I want to tell you my understanding about it.
JDK (Java Developer's Kit) is a complete Java development platform. We can compile, debug and run the code. The JDK depends on the operating system, so there are a little version classify by Windows, Linux and Mac.
JRE(Java Runtime Environment) is the runtime environment of Java. If you had ever played any game which written in Java, you can find that you must have JRE when you is going to play the game. This is the Java Runtime Environment.
JVM (Java Virtual Machine) is a part of JRE. It is the most important part of the JRE.
JIT is the tool which can transform bytecode to the binary code.
javac is the tool which can transform code to the Java bytecode.
We can conclude the relationship:
JDK = JRE + javac + jconsole +jvisualvm + demo + document + other
JRE = JVM + JAVA binary code + other library + other
JVM = JIT + Other

GCJ: Java native code, won't run on other machines

I tried GCJ and it compiled fine. I tried both for Ubuntu and windows. The compiled file is running on my Ubuntu machine as well the .exe with wine. But if I tried to run in on my Ubuntu server I got this error:
error while loading shared libraries: libgcj.so.14: cannot open shared object file: No such file or directory
But I thought I would not need to install anything to run "native" code. I also could not run the .exe on a windows machine.
Could you please tell me why this is happening? Maybe I'm compiling wrong. I use this: gcj --main=Hello -o hello.exe Hello.jar for windows.

When you run an executable it is very common to need a shared library, whether you use Visual Studio .NET or Java or C++.
When you compile a program for a specific platform, it usually only works on that platform or similar. If you want to run this program on Windows, you need to compile it for windows.
BTW GCJ is pretty old and out of date. I suggest you use Java 7 or 8. This will avoid the need to install additional libraries and will run on Windows or Linux without re-compiling.

Running Windows-compiled C++ program on Linux machine using Runtime

I need to run an executable on the command line through Java. I have seen a lot of information about this and using the Runtime object to execute the file. However I have a problem: the executable is written in C++ and compiled for Windows, but I'm using Linux. I have no access to the source code.
I read in the documentation of the Runtime environment that
Runtime that allows the application to interface with the environment in which the application is running
The environment I am running it on is Linux, so the application would not work if the application is interfacing with my Linux environment.
I am curious if there are any other objects other than Runtime that could do this, but mimic the runtime of a different OS. For example maybe a WindowsRuntime object or something that you could call and have the application run without having to recompile it for Linux. It seems like this could be pretty complicated (perhaps like a virtual machine) but thought it was worth a try.

Compile 32 bit from Win7 64 bit

I would know if is possible compile a java desktop application in 32bit application
from Windows 7 64bit using Netbeans.
Thx you for HELP.

You don't have to build java code for 32-bit or 64-bit platforms. The code is compiled to byte code which is run by JVM. You can use 32-bit or 64-bit JVM to run your java code.
The only exception is native libraries that you might be using in your code. If there are any then you will have to manually compile those for the respective platform. Otherwise the java code is totally portable across 32-bit and 64-bit platforms.
Write once and run everywhere :-)

Java doesn't build 32-bit or 64-bit applications - bytecode is portable across architectures.
If you rely on any native libraries, you'd have to potentially ship both versions of those - but the actual Java code won't need to be recompiled.