Delegation also often pre-supposes that we want whomever we delegate TO, to be able to grow so as to to fill bigger shoes some day?

So if one is like the rest of us, then we genuinely * WANT TO * delegate ... allot! -Yet when we trust others to do the things that we could otherwise do ourselves, an extra overhead often accompanies most types of inter-office delegation. -New efforts that often include skills that require an ability to (1) follow up, (2) managing cyclic results, (3) communicate & update objectives, and (4) more! --Chores which are often only worth our extra effort if / when we want those whom we trust, to become better?

Little wonder most feel that it is simply easier to 'do things for oneself', then to 'delegate'?

Of course, over time one will notice that while some folks are able to properly manage the trust required for task delegation, others, cannot. --Indeed, the difference between being a ''leader'' and merely being ''in-charge'' precisely hinges upon the ability to grow others... -Our personal ability to manage many trust-relationships. --An ability to intuitively assign proper tasks... as well as proper rewards!

It's About Time

Anyone who develops software in their spare time knows that the choice over how to spend that time is often budgeted between re-testing, or adding cool features.

Testing Word

Indeed, as we consider how tighter security is causing many programs to fail on Microsoft Windows, the word on the street for anyone who has not tested their programs in the past 3 months should be to do so - and to test across as many OS flavors as possible.

Crazy Problems!

Once Java has been installed on your computer, EzLog4J was designed to run from a simple click. Since our latest install of 'Windows 7 with the Oracle 7 platform-invocation randomly decided to use WebStart (!), a clicking on ezlog.jar thereunder fails with a JNLP Error.

Oddly, the new default is to use WebStart. From there, to treat Java as hostile even on your own local machine.

In other words, without even the slightest hint of any web-start support requested in the .jar file, if your Java Application is not code-signed, then it will no longer run on Microsoft Windows! Even worse, Oracle insists that self-signed code will shortly be going the way of the Dodo.

(sigh)

Yes, we could educate all would-be users how to do an "open with" to run our .jar files with some other launcher, but fortunately there are several simple work-arounds. Techniques that we developers can take to effectively side-step this ever-growing .jar lock-down problem.

For lack of time, we employed the easiest of the lock-down avoidance lot -- batch files & "start" commands:

cd .\diststart javaw -jar ezlog3.jar

~ or ~

cd .\distjava -jar ezlog3.jar

How does the alternate file-name approach work? -Well, since most folks ignore those file types / descriptions on Microsoft Windows ANYway, my friends will still "start" my program by clicking on the "ezlog.bat", rather than that evil "ezlog.jar" file. --All anyone will be looking for is to click on the word "ezlog" anyways. (Muhhhahah-ha)

The .EXE End?

What comes next? Rather than brandishing console-laden command prompts everywhere, everyone who does not want to pay $100 / month for a certificate will surely be creating an .EXE, next (which the planetary-wide free Java Tooling - at the time of this writing - will not create!)

--Might all of the above .jar lock-down silliness be more evidence that Oracle is indeed trying to kill Java?

.Batter-up

So because 'Windows accounts for about 80% of the EzLog4J Project downloads, last night we provided a new ezlog.bat start-up file. To run EzLog4J on 'Windows, merely merely download & unpack the zip file from SourceForge to click on the same from within The Microsoft Windows File Manager.

In a like manner, Linux & OS X Users can try the virtues of the included ezlog.sh file.

p.s.

Along the way, we discovered & fixed a voice-file playback buglet, as well. -Hence the .01 suffix on this Version 3-Release.

(Perhaps Nietzsche was right: That which does not kill us, makes us stronger?)

After reading yesterday's article, those who remain curious over how to properly manage IPC on Windows & POSIX might enjoy our new, simple, Framework. (Note that the source code is included in the download / jar file.)

"The IpcStringReader Class will monitor the results from an executing process so as to:

(1) Present lines-read to a collector line-by-line.

(2) Keep from hanging-up when a process fails and

(3) Allow us to gracefully accept and / or terminate our result line-reading activities when desired.

Designed to quickly & efficiently manage the result from one or many concurrently running (IPC) Processes, see the test cases for examples on how to use this Package."

NOTE:The test cases in this Package also demonstrate how to use the java.util.concurrent.ExecutorService tooling.