Site Sponsors:
Java IPC and Microsoft Windows 
Since the 1970s, folks in the C World have long been enjoying the benefits of "piping" things between processes. Piping is easy, it is fun, and (with a single invocation work-around on Microsoft Windows) piping works pretty much the same everywhere.


While we have been able to start, read, and pass information to other programs on Java for awhile now, everyone knows that - far from "Write Once, Run Anywhere", using Processes under Java can be a very platform – let alone operating system process - specific undertaking.

Process Woes


Interestingly, the first cross-platform IPC problem has very little to do with Java. When working on 'Windows, the most frequent errors encountered often simply have to do with (1) where the program is located / invoked, as well as (2) how we use Java to manage the input and output streams.

Location Matters


For those who are new to programming, the first thing to do is to note that some of the commands we use at a terminal (or "shell") are built-in. Others are external. Hence whenever we type "ls" on Linux, or "DIR" on Microsoft Windows we are not executing an external command. What we are instead doing is executing a built-in ''shell'' feature.

Command-Line Parsing


Unlike our single space-separated string convention on POSIX, Microsoft Windows expects commands to be passed to its command shell via a series of strings. In this way, Java and C/C++ have the same requirement on 'Windows. Both exec() a command shell under the same constraint.



After the obvious however, the second problem begins to bear its teeth: when reading input from a stream on Java, unlike in C/C++ there is no “putc” or “push_bask” capability. Hence, anti-blocking stream pre-read / put_back testing is not possible. We must use .ready(), instead.

What's wrong with using a Reader's “ready()” feature, you might ask?

Well, to begin with, most folks do not use it. --Indeed, whenever ready() is used, rather than simply a “put back” ability, crafting clever “look ahead” and / or time-out checking loops require a block or two more code. (see below)

Reading CMD.EXE Responses under Java


So after the common Windows invocation differences, forever-blocking on any type of buffered / un-buffered read is often the next problem to tackle.


Unlike the former Windows invocation problem however, our second problem is common on POSIX, as well. Our common solution is that in Java, before we read a shared IPC Stream, we had better check to see if it is ready(). Why? Because not only can streams go cross-platform 'zombie on us during even an un-buffered read, but trying to fix the problem – along with dodging common threading problems - might just eat our brain :-)


import java.io.InputStreamReader;

public class ProcOne {

static int BY_LOOP = 7;

public static void main(String[] args) {
try {
String[] data = { "CMD.EXE", "/C", "DIR", ".." };
Process proc1 = Runtime.getRuntime().exec(data);
InputStreamReader is = new InputStreamReader(proc1.getInputStream());
int ch = 0;
do {
int times = 0;
while (is.ready() == false) {
times++;
Thread.sleep(300L);
if (times > BY_LOOP) {
break;
}
}
if(times > BY_LOOP)
break;
ch = is.read();
if(ch != 0)
System.out.print((char)ch);
} while(ch != 0);
is.close();
} catch (Exception e) {
e.printStackTrace();
}
}

}

If you have any doubt, then (2) remove the IO Checking Block then (1) merely change data in the above to a single String: "CMD.EXE /C DIR .." Finally, before debugging (0) pretend you never saw this post & go grab your next-door neighbours shotgun ...

Enjoy the Journey!

(p.s. - Later that evening we encapsulated the above concepts into a simple-to-use Framework. The design allows us to incorporate the events from one - or hundreds - of clustered (cloistered?) IPC Activities into a graphical / textual user interface (GUI/TUI.) See the IpcReader Project on SourceForge for more information.)

[ view entry ] ( 1772 views )   |  permalink  |  related link
GWT + PHP = Client + Server 
Much like GWT, I have been thinking about wrapping-up PHP in Java's toStirng() to manage our server-side PHP for a few months now. ...

Before I started yet another Open Source Project (something to complement PHP CRUD), today I am happy I discovered GwtPHP.

Like myself, all PHP CRUD enthusiasts should perhaps be planning to put GwtPHP thru its paces as time & availability permits... Feel free to let the rest of us know if you love it?

Sharing is caring!

p.s - Just in case you were wondering:



[ view entry ] ( 1866 views )   |  permalink  |  related link
LinkedIn: What causes a company to fail? 
(see "related link", below)

"No matter how we choose to define "failure", there seems to be three common causes:

(1) I believe that the number one reason why companies fail today is because few know how to recognize talent & promote from within. An MBA from Harvard is no substitute for a home-grown account who knows both your business model, as well as your industry. Also, unlike yesterday's "Peter Principle", another problem today is that someone who is competent at what they are doing is simply too valuable to promote?

(2) Next, companies stumble when they can no longer define, refine, support, and / or market a clear company (or business unit) mission statement.

(3) Finally, the inability to understand, obtain, and / or support pro-active mission support and / or delivery personnel is also far too common these days.

In retrospect, I also see that more "missions" than ever are failing simply because folks have far-outsourced their trust to cheap and / or inexperienced talent.

Yet in general, one typically only gets what one pays for. Indeed, well before our present problems with far-outsourced meltdown, 80% of all IT Projects failed. --Can anyone possibly expect that number to DECREASE when adding opposing languages, time-zones, cultures, as well as thousands of miles, into the mix?"

[ view entry ] ( 2828 views )   |  permalink  |  related link

<<First <Back | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | Next> Last>>