Before I continue, I'd have to mention that one of the stand along java programs would have to (and does very well) interface into a scheduling tool. This scheduling tool is a cots product. Generally, this tool will start predefined files or scripts at the predefined times. The interface to this scheduling tool is generally to get a connection to it, read the data (it comes back in a result set), and parse the data. Don't forget to close that connection. Sounds like a database. It is very similar.
Back to the story, there was a short learning curve to re-acquaint myself with how to run a stand alone Java and a C program. The learning curve and internet shows there is the ProcessBuilder way, and the Runtime.getRuntime().exec("java Main"); So I used both. Not a big deal, it was a good learning experience. If I was to deploy this code, I'd be ok with using both methods.
What I did find was the program, when run within netbeans, I could not find where netbeans wrote a default file as I had not defined a full path. Your saying, "dude, this is in that netbeans project top level directory." Now you tell me. So as that story went, using the brute force method, "find . -name "myfilename.txt" {} \; Well low and behold, there it was, just like you said, in the netbeans top level directory of this project. This was a good lesson learned.
The overall design of this project is the the gui contains several jtext areas which have predefined text (strings). As the user chooses an item in each of these jtext areas (Mouse Click Event), that chosen string finds its way into a String outStr = new String. As each item is chosen across each of the jtext files, they are concatenated with a comma. Basically, the output is a String of text and is separated by comma's.
Once all the jtext areas have been looked at and the outStr is complete, the user presses a Load button. This load button essentally takes that outStr and puts it in a buffer which is then written to a outfile. It is written to the outfile when the user presses "Send".
Now this Send does three things. It is the Event Handler that writes that String to the outfile.txt, then runs (java-program-1) which reads the outfile.txt and creates a special input file for that scheduling program. Next (c-program exe) is called which has some special calls that serve to load that special input file into the scheduler. Finally, (java-program-2) reads the scheduler and presents that output to the user. This is to give the user a confirmation that the scheduler in fact has the data. It all worked out pretty well.
The other concept that was a good lesson was the use of creating jar files for those two java programs (to store the class file). Also, the need to code a c shell script which will set the necessary environment, CLASSPATH and all that good stuff. That latest lesson took about 4 hours to learn from trial and error. Sure, the internet is full of good stuff. But this customized application and my development environment is something that is not on the internet.
So the bit take away's were: If you don't specify a full qualifying path, netbeans writes it to the project top level directory. Second is to keep an open mind and expect to write a shell script, it will have a CLASSPATH, other environment stuff and will call you jar file. Oh, by the way it is these scripts that were called with ProcessBuilder and/or the getRuntime.exec().
