Pulling a program out of the IDE

Question

I have been playing with pulling small progrograms out of my Integrated development environment (IDE); writing them to CD; and installing them on other desktops, just as an exercise in the case I want to deliver some applications to a friend.
The overall requirements(steps) are not clear to me.
1.the directory organization
2. the file (jar) creation
3. the D0S (java.exe) window
Are some of the issue that come to mind.
I have been able to use a desktop icon and set the path to a program.class file and run it--making the program window appear but the java.exe Dos window also appears.
So far, the number of texts I have give no step by step instructions on how to configure an environment without an IDE with the java VM already intalled, or how to pull a program out of the IDE and install it along with a copy of the VM on another machine.

Answer 1

Good question. Lot's of people don't know this, and I can't even say I have all the right answers. There are probably numerous ways you could do this. The best way, if you have the money, is to buy something like InstallAnywhere or Wise that provide professional installations. Not only will your install look like professional installation of stuff like Photoshop, etc but it will also handle issues like OS platform specifics, environment variables, registry entires (if possible), the proper JRE/JDK installed... if not install it, uninstallation features, and so forth. That is by far the best way to go.
However, often you just want to bundle something up and send it out to a few friends, family, etc. You could of course look for an open source or freeware utitlity and no doubt there are some out there. Or, you could do what a lot of people do now, use the Ant tool (written in Java) and have a build script that does everything for you. I have a simple template build script that is used for various tasks. In our work setup, it does local dev (incremental) compiles, and if necessary packaging it up into .jar/.zip files. My single build script can also run junit tests and reports, builds executable packages into .zip and .jar's as necessary, will do a clean build (great for making sure any code changes don't break some code elsewhere, thus ensuring that your normal incremental build process is not missing something), it can FTP or copy files to locations, it can email results, and so forth. If you don't know about ant, I STRONGLY suggest you learn it quickly, and to me there is no better way than buy the book Java Development with Ant. Two of the main Ant developers/committers wrote the book and it does an excellent job of teaching you about all the different uses of Ant, including the template build script I now use. It is well worth the $40 or so you'll find the book for, and within a week you'll have a good build template that you can modify for specific projects.
Now, in terms of the 3 things, well, the directory organization is always changing. Each project may have something different, but here is one that I usually use:
<root project dir>: (below this you'll find)
/src - location of all src files
/src/java - the location of the project specific java code
/src/examples - if need be (especially useful for frameworks and API's you wish to share) show example applications using the output of the /src/java code
/src/test - location of JUnit, jfcUnit and other test files to unit test your code (very important, should be done no matter what!!)
/lib - location of any 3rd party libraries you need, both for compilation and runtime. Keep in mind that your build script may pull only a subset of these libraries in for runtime. For example, the /src/test that uses JUnit will require the junit.jar file. You won't need this for runtime, so your build script sets up a compile classpath with junit.jar, and a runtime classpath that will exclude junit.jar, perhaps others.
/dist - the location that the build script puts all distributable files. This would be any executable .jar file, any .zip file, perhaps other files necessary for distribution. If you were making a large application and planned to burn it to disk, instead of a single .zip file, you may actually build the sub-dirs below the /dist/<your app> type of dir, so that you can simply burn from that <your app> dir to the root of the cd.
/build - location of all compiled classes, including from /src/java, /src/examples, /src/test.
/build/classes - the location of compiled java code
/build/test - the location of test results, including perhaps test data to be used by the test code, and possibly the output dir of test reports
- /build/test/reports for example for output of test reports.
/doc - location of any documentation, including the JavaDoc produced by the build script from your src.
<project root> - this is the location of your build.xml ant build script, if need be. The build script, as you would learn in the book, is set up so that you can move it anywhere and it will still build your project correctly. You may opt to put it in the /scripts dir instead and keep the project root super clean.
/misc or /etc - common location to put things like properties files, misc files used to build projects. For example, in the building of a EJB application (.jar or .ear file), you will no doubt need the META-INF/application.xml file. Or in a .jar file you need a special META-INF/manifest.mf file. The /misc or /etc dir is a good candidate for these types of things. You can even package it up in your app so that in the .jar file you have /etc/properties/somepropertyfile.properties, and in your code do a simple getClass().getClassLoader().getResource("/etc/properties/somepropertyfile.properties") to always ensure you pull it from this directory. OR, your build script can "change" the location this file goes. It is all up to you.
That is what I use for all my projects, the dir structure anyway. What you do to build your .jar/.zip files is up to you. You usually don't need to pull the /src dir, the /dist dir, etc into your .jar/.zip files. Normally you'll have the compiled classes at the root. So in your project dir on your disk, you may have <project root>/build/classes/java/org/mycompany/ui/Main.class, and in your .jar file it would simply be <root of .jar file>/org/mycompany/ui/Main.class, and your build file can easily "change" the root path (using <zipfileset prefix=""> task) to change the path of any file. But more of that can be learned in that book and by looking up resources on the net. The Ant JavaDoc API is very good at explaining most of these as well, and there are TONS of ant scripts in most projects to look at for examples.
The file creation, well, as I said Ant has built in tasks you can use to create .jar files, .zip files, etc. All of that is all built in to how Ant works.
As for java.exe, well, in a professional app, you usually do one of two things. You either write a simple C/C++/Delphi/some other languages .exe wrapper (for windows) that internall executes the java.exe and runs the JVM to hide the window, as well as provide a .exe file to look more "native", or you run javaw.exe, which hides the Console output window for most apps. NOTE: if you create a .bat shortcut on your desktop to javaw.exe, you will STILL get a console window that shows up. ALL shortcuts to .bat files will always create a console window. Many java developers don't understand why they run javaw.exe from a shortcut on their desktop and still see the console window.
Now, hopefully that helped a bit. But if not, or you still have questions, I am watching this thread so fire away and I'll help more.