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.

How java finds native libraries? [duplicate]

I would like to know when do we need to place a file under
C:\Windows\System32 or C:\Windows\SysWOW64, on a 64-bits windows system.
I had two DLL's, one for 32-bit, one for 64-bit.
Logically, I thought I'd place the 32-bit DLL under C:\Windows\System32, and the 64-bit DLL under C:\Windows\SysWOW64.
To my surprise, it's the other way around! The 32-bit one goes into C:\Windows\SysWOW64, and the 64-bit DLL goes into C:\Windows\System32.
Very confusing stuff. What's the reason behind this?

I believe the intent was to rename System32, but so many applications hard-coded for that path, that it wasn't feasible to remove it.
SysWoW64 wasn't intended for the dlls of 64-bit systems, it's actually something like "Windows on Windows64", meaning the bits you need to run 32bit apps on a 64bit windows.
This article explains a bit:
Windows x64 has a directory System32 that contains 64-bit DLLs (sic!).
Thus native processes with a bitness of 64 find “their” DLLs where
they expect them: in the System32 folder. A second directory,
SysWOW64, contains the 32-bit DLLs. The file system redirector does
the magic of hiding the real System32 directory for 32-bit processes
and showing SysWOW64 under the name of System32.
If you're talking about an installer, you really should not hard-code the path to the system folder. Instead, let Windows take care of it for you based on whether or not your installer is running on the emulation layer.

I should add: You should not be putting your dll's into \system32\ anyway! Modify your code, modify your installer... find a home for your bits that is NOT anywhere under c:\windows\
For example, your installer puts your dlls into:
\program files\<your app dir>\
or
\program files\common files\<your app name>\
(Note: The way you actually do this is to use the environment var: %ProgramFiles% or
%ProgramFiles(x86)% to find where Program Files is.... you do not assume it is c:\program files\ ....)
and then sets a registry tag :
HKLM\software\<your app name>
-- dllLocation
The code that uses your dlls reads the registry, then dynamically links to the dlls in that location.
The above is the smart way to go.
You do not ever install your dlls, or third party dlls into \system32\ or \syswow64. If you have to statically load, you put your dlls in your exe dir (where they will be found). If you cannot predict the exe dir (e.g. some other exe is going to call your dll), you may have to put your dll dir into the search path (avoid this if at all poss!)
system32 and syswow64 are for Windows provided files... not for anyone elses files. The only reason folks got into the bad habit of putting stuff there is because it is always in the search path, and many apps/modules use static linking. (So, if you really get down to it, the real sin is static linking -- this is a sin in native code and managed code -- always always always dynamically link!)

Ran into the same issue and researched this for a few minutes.
I was taught to use Windows 3.1 and DOS, remember those days? Shortly after I worked with Macintosh computers strictly for some time, then began to sway back to Windows after buying a x64-bit machine.
There are actual reasons behind these changes (some would say historical significance), that are necessary for programmers to continue their work.
Most of the changes are mentioned above:
Program Files vs Program Files (x86)
In the beginning the 16/86bit files were written on, '86' Intel processors.
System32 really means System64 (on 64-bit Windows)
When developers first started working with Windows7, there were several compatibility issues where other applications where stored.
SysWOW64 really means SysWOW32
Essentially, in plain english, it means 'Windows on Windows within a 64-bit machine'. Each folder is indicating where the DLLs are located for applications it they wish to use them.
Here are two links with all the basic info you need:
MSDN File System Redirector
SysWow64 Explained
Hope this clears things up!

System32 is where Windows historically placed all 32bit DLLs, and System was for the 16bit DLLs. When microsoft created the 64 bit OS, everyone I know of expected the files to reside under System64, but Microsoft decided it made more sense to put 64bit files under System32. The only reasoning I have been able to find, is that they wanted everything that was 32bit to work in a 64bit Windows w/o having to change anything in the programs -- just recompile, and it's done. The way they solved this, so that 32bit applications could still run, was to create a 32bit windows subsystem called Windows32 On Windows64. As such, the acronym SysWOW64 was created for the System directory of the 32bit subsystem. The Sys is short for System, and WOW64 is short for Windows32OnWindows64.
Since windows 16 is already segregated from Windows 32, there was no need for a Windows 16 On Windows 64 equivalence. Within the 32bit subsystem, when a program goes to use files from the system32 directory, they actually get the files from the SysWOW64 directory. But the process is flawed.
It's a horrible design. And in my experience, I had to do a lot more changes for writing 64bit applications, that simply changing the System32 directory to read System64 would have been a very small change, and one that pre-compiler directives are intended to handle.

Other folks have already done a good job of explaining this ridiculus conundrum ... and I think Chris Hoffman did an even better job here: https://www.howtogeek.com/326509/whats-the-difference-between-the-system32-and-syswow64-folders-in-windows/
My two thoughts:
We all make stupid short-sighted mistakes in life. When Microsoft named their (at the time) Win32 DLL directory "System32", it made sense at the time ... they just didn't take into consideration what would happen if/when a 64-bit (or 128-bit) version of their OS got developed later - and the massive backward compatibility issue such a directory name would cause. Hindsight is always 20-20, so I can't really blame them (too much) for such a mistake. ...HOWEVER... When Microsoft did later develop their 64-bit operating system, even with the benefit of hindsight, why oh why would they make not only the exact same short-sighted mistake AGAIN but make it even worse by PURPOSEFULLY giving it such a misleading name?!? Shame on them!!! Why not AT LEAST actually name the directory "SysWin32OnWin64" to avoid confusion?!? And what happens when they eventually produce a 128-bit OS ... then where are they going to put their 32-bit, 64-bit, and 128-bit DLLs?!?
All of this logic still seems completely flawed to me. On 32-bit versions of Windows, System32 contains 32-bit DLLs; on 64-bit versions of Windows, System32 contains 64-bit DLLs ... so that developers wouldn't have to make code changes, correct? The problem with this logic is that those developers are either now making 64-bit apps needing 64-bit DLLs or they're making 32-bit apps needing 32-bit DLLs ... either way, aren't they still screwed? I mean, if they're still making a 32-bit app, for it to now run on a 64-bit Windows, they'll now need to make a code change to find/reference the same ol' 32-bit DLL they used before (now located in SysWOW64). Or, if they're working on a 64-bit app, they're going to need to re-write their old app for the new OS anyway ... so a recompile/rebuild was going to be needed anyway!!!
Microsoft just hurts me sometimes.

Make Installer of java Application

I have tried this two setup for making installer of java application.
Exe4j
Inno setup
I have used these 2 setups for making a java application installer.but when I installed on another operating system (Microsoft OS) windows 7 or 8 then its gives error No JVM could be found on your system...
I am stuck in for 2 days.
java application store data into 2 text file and then on text file generate at run time and then delete generated file after some processing. I don't know how should I generate a setup for java application....please anyone?

This might be of interest launch4j. It's possible to wrap applications on Windows, Linux and Mac OS X and can be configured to search for a certain JRE version or use a bundled one

We also have a feature in Advanced Installer, Java edition, that can be used to package your Java application for Windows and for Mac OS.
Here is a 1 minute video that shows how easy it is to build your installer.
Advanced Installer also has the ability to bundle a specific JRE version inside your installer, so your application will use only that JRE, no matter if on the end user machine there is another version of JRE or none at all.

Make jar run in 32bit jre

How can I specify that in order to run a certain java application that I created you need to have 32 bit JRE installed on your system? Further how can I specify that the java application is to use the 32 bit JRE and not the 64 bit JRE if they are both installed?
Background:
I have created an application that uses a 3rd party 32 bit only library. The application can not run in a 64 bit JRE.
I am going to be distributing this application to a lot of computers in my company, so I need to be able to in code or in the export process, specify the required JRE.
I am using eclipse, Kepler to develop and build the java application.

The idea of java is always compile once and run everywhere, regardless of OS, cpu architecture etc, so you might be heading the wrong direction here.
But nevertheless here are some system properties you might / not find helpful. I've listed the property key and value I have when I check it (I run Oracle JDK on Win7 64)
java.vm.name: Java HotSpot(TM) 64-Bit Server VM
sun.arch.data.model: 64
sun.cpu.isalist: amd64
To use any of those just do
String vmname = System.getProperty("java.vm.name");

You can't do it directly in Java, since you're in a running JVM at that point. My solution was to write a dos batch script to set the JAVA_HOME and add %JAVA_HOME%\bin at the front of the PATH. For example, I have sethome.bat which contains
#echo off
set "JAVA_HOME=c:\Program Files (x86)\Java\jre6"
set "PATH=%JAVA_HOME%\bin;%PATH%"
Then I use
call "%SERVICE_HOME%\sethome"
"%JAVA_HOME%\bin\java" -version
echo If this does not look correct press CTRL-C to cancel otherwise
pause

You cannot generally make sure what program runs your jar. I can pass the jar to acroread, or zip or whatever, and you can't do anything about it.
So, I'd just try to load the library, and do a proper error/exception handling. Who knows? Maybe your client has meanwhile replaced that library with a 64bit version, without you knowing about it? SO, this: loading, and if it won't aborting with a graceful eror message is the only sensible thing.

Eclipse intermittently fails to create the Java Virtual Machine

I am using Windows 7 32-bit OS. I am using Eclipse 3.7 (Indigo) 32 bit. I have jdk1.7.0_07 32-bit installed. And sometimes when I go to run Eclipse as administrator, I get the following error message,
And when I tap "OK", I get the following error message,
And sometimes I get this error message. And at other times, Eclipse will launch, but fail when Gradle goes to initialize its VM when attempting to start its daemon process.
What's happening? I realize it's a memory issue, but why am I able to launch Eclipse once in a while and run everything just fine? And at other times, why I am able to launch Eclipse but not able to run anything, or unable to launch Eclipse at all?
As a developer, this behavior is a nuisance.

Try -Xmx900m. The problem might be with the eclipse.ini file.

I've had this problem with JDK7. I've found that i do better with eclipse if it runs under Java 6, and then you add JDK7 as the runtime environment for your project.

Make sure that your eclipse matches your jre/jdk bitwise. If you are using 32-bit eclipse, you must use 32-bit jdk.
Your -vm param is wrong. The arg must start on the next line like this:
-vm
c:\Program Files\java... etc
When the JVM (Sun's JVM) starts it allocates the heap as a single malloc, a single contiguous block of memory. If, for any reason, that much contiguous memory is not available then the JVM will not start. Without debugging your machine is hard to know what could be blocking a big malloc. Note that some viruses recently have been taking shelter inside the jvm.

you said that your's is a 32 bit os is you your eclipse is 32 bit compatable or 64 bit if it is 64 bit remove the java related folder in your eclipse and replace it with 64 bith java sdk this will work i got this problem and i got it solved in this way.