Site Sponsors:
Unit Testing Today 
In 2009 and 2010, the United States Army asked me to write several papers on modern software capabilities.

Inspired by what I discovered on recent unit testing advancements, I have written an article on unit testing. One that I would like to share:

[ Unit Testing Today ]

While the observations in the above focuses a little more on .NET & Microsoft software developer tools than I would prefer, I believe that this paper has a little something for everyone.


[ view entry ] ( 3288 views )   |  permalink
Java Processes - Java Jive? 


Our quest to find an elegant solution to the random Platform / Process hang-up (zombie) read-problem lead to the creation of an Open-Source Project.

Cross-platform and easy to re-use, you will recognize some of the following code as par for the Microsoft Windows & POSIX / Linux Test Cases of the IpcReader Project!


Common Problem

It should have been noticed well before now - but since it is a problem, it should be documented. That way someone can fix it.

The Story

Because 3rd party code tends to break over time, I have been contemplating putting together a few Java 'wrappers' around some strategic external commands. Shelling out to do things like FTP, TAR (etc.) could come in very handy!

Though implementations can differ wildly, wrapping external commands would be far more stable over the eons. -Certainly across the desktops I like to write software for (i.e. Linux, Mac, & Windows.)

The Code

So after trying the 'old' way of starting a command from Java:

Process proc1 = Runtime.getRuntime().exec("ps ax");

-We noticed that trying to do such for a genuine external command, simply did not work on Ubuntu (at least, nut under my current 1.6 version of the Sun/Oracle JVM). While everything seems to run just-fine, trying to read a stream from an executed external command winds up hanging any read-operation in a forever-loop:

Process proc2 = Runtime.getRuntime().exec("/bin/tar");

So what's a good geek to do? -Why, ask other enthusiasts, of course.

Thanks, Stack Overflow!

After scanning over a decade's worth of 'solutions' to the 'we cannot read the process stream' problem, I decided to create the definitive example. An all-in-one class. A single demonstration that incorporated every approach proposed by every-one I could 'google-to.

Here is the best thread:

[ Community Observations ]

Of course I posted the approach at a few places. But I was pleased to get so many interesting responses in so short a time from StackOverflow.

Bottom Line

To save you some reading-time, lets summarize by noting that sometimes using

Process proc3 = new ProcessBuilder("/bin/tar").start();

-is better. Curiously however, sometimes using


works just as well.

Of the two approaches, we have noted on our platform that while ProcessBuilder fails to recognize 'internal' shell commands, on my machine using ProcessBuilder gives the best results. For me & for now, only ProcessBuilder will properly invoke those external commands.

Conversely, when wanting to run those exact same internal commands, at the time of this writing that classic toolkit is by far the easiest way-to-go. (i.e. No need for scripting, invoking sub-shells, writing daemons, channeling druids, etc.)

'Der Code

Until our various JDK 'gurus catch up with this observation, allow me to share the following code. -Something everyone might quickly try for themselves:

package Problems;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class RunningProblem {

public static class RunningReader implements Runnable {

private Process proc;
private String sName;

private RunningReader(Process proc1, String sName) {
this.proc = proc1;
this.sName = sName;

public void run() {
try {
InputStreamReader in = new InputStreamReader(proc.getInputStream());
BufferedReader reader = new BufferedReader(in);

String line = reader.readLine();
while (line != null) {
System.out.println(sName + ": " + line);
line = reader.readLine();
} catch (Exception e) {

public static void main(String[] args) {
ExecutorService pool = Executors.newFixedThreadPool(3);
try {
Runtime rt = Runtime.getRuntime();

Process proc1 = rt.exec("ps ax");
RunningReader reader1 = new RunningReader(proc1, "reader1");

Process proc2 = rt.exec("ls -l /");
RunningReader reader2 = new RunningReader(proc2, "reader2");

Process proc3 = rt.exec("/bin/tar");
RunningReader reader3 = new RunningReader(proc3, "reader3");


} catch (Exception ex) {
} finally {
System.out.println("Launcher.main() Exited.");

Conversely, here is the latest way to do the same thing using ProcessBuilder:

Process proc1 = new ProcessBuilder("ps ax").start();
RunningReader reader1 = new RunningReader(proc1, "reader1");

Process proc2 = new ProcessBuilder("ls -l /").start();
RunningReader reader2 = new RunningReader(proc2, "reader2");

Process proc3 = new ProcessBuilder("/bin/tar").start();
RunningReader reader3 = new RunningReader(proc3, "reader3");

-Just paste those six lines over their classic equivalent, after trying it.


If you can take a moment to comment on this thread after trying the above, then we can all learn what-works on which-platform someday.

May the source be with you... Always!


[ view entry ] ( 2498 views )   |  permalink  |  related link
Don't be a Monkey! 

Another Chimp, Chump?

I do get SO tired of the monkey-shine. (No, this time I will not treat you to yet-another politically-incorrect pseudorant on neo-politico-religious values. Un-uha.)

What has gotten my goat during lunch today is yet another clueless company. This one, a computer consulting firm: They are using a 'webco that is trying to fool us into giving them our personal information.

And what could be more personal with our email address, than our very-own computer's IP address? -All just sitting ripe and ready in the html server-logs; Combined with any seemingly anonymous data we might foolishly provide to them, poised for yet another denial of service attack, mindless email marketing campaign, or perhaps even a web-mail-cookie email invasion?

Yawn, yawn, yawn ... !

Since the time of 9600 BPS modems, most of us geeky-folk have know that, whenever we create an HTML link (aka: "anchor"), that we have to supply both a "link", and the "human-viewable" part.


<a href="">You only see this part</a>

What is so annoying about the abuse of this seemingly innocent convention today is that whenever you click on 'You only see this part', the computer gets the 'my_code_to_id_you' 'stuff sent to it.

What is the point?

For decades we have all know that if anyone chooses to click-on such a emailed link, that by using a unique my_code_to_id_you value, that we can instantly know that YOUR EMAIL ADDRESS has done so. All I need do is generate a unique number, and use it as the URL suffix, as shown above.


What gets me whenever I see things like the following so often today - is just how stupid do they think we are?

I mean, it is bad enough that they are so DECEITFULLY trying to pull the wool over our eyes. --But by pretending that the HUMAN readable part is just any plain-old URL - and that (who, me?) it is going to make NO attempt to associate your personal information with their innocent fact-finding attempt... just plain 'old makes me sick.

Ho well. On a scale of 1 to 10 on the annoyance meter, this is probably a clear five... but, by way of the final insult, guess what the name of the offending webco is calling itself?


Yup - Unreal, no?

So do yourself a favor: Always check your URLs' before clicking them. --Don't let the link banana-chasers make yet-another monkey, out of you!


-R.A. Nagy

[ view entry ] ( 3381 views )   |  permalink

<<First <Back | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | Next> Last>>