RE: FW: Java Vs RPG on iSeries -- JAVA400-L

> From: Larry Loen
>
> Java has done something very significant here -- Java has deskilled the
> process of writing multi-threaded apps compared to any other programming
> language I know of.  Multi-threading is not as sophisticated a task in
> Java, in other words, as it is in other languages.

Multithreading has two distinct meanings.  The first is the actual machine
implementation of multiple threads executing the exact same code, and thus
requiring the low-level synchronization of shared memory spaces.  That
level, which Java takes care of quite elegantly, is primarily involved with
providnig asynchronous processing of unrelated events, and isn't very
relevant to a business application programmer.

The second is in the more general sense of a single control task spinning
off multiple subtasks to split up the processing load.  This is more
precisely termed multi-tasking rather than multi-threading, because there is
no real benefit from these individual subtasks being lightweight threads as
opposed to heavier processes.  This is parallel processing, and has little
or nothing to do with the language specific implementation.  You can do the
same thing in RPG as you can in Java.  The issue is to properly design your
problem set so that multiple subtasks can process a subset of the problem
independently.  This level of expertise is absolutely foreign to most
programmers.

For example, you can properly design a cost rollup so that multiple tasks
can be running simultaneously, thereby reducing the disk bottleneck.  It
requires properly segregating your database into processing tiers and making
sure that the a higher tier doesn't outstrip a lower tier.  This is way,
way, way beyond the ken of most application programmers.


> Also, without making this a very long treatise, I will state that:  ". .
> .expertise not generally available in ANY market" would be disagreed with
> by those in various Unix or NT markets, including people who
> write code for
> banks and like businesses.  Plenty of programmers have used far inferior
> tools from C to do this multi-threading stuff and have for a long
> time now.

For what?  What business application in banking regularly requires
lightweight thread processing?  And I'm not talking about communications or
encryption or UI; I'm talking business application.


> Where do you think the incentive came from for the Java designers
> to invent
> all this?  Not everyone does their locking in the data base.

Of course not.  But I don't think the Java Thread class was added to provide
parallel processing of business applications, but instead to emulate the
concept of an asynchronous daemon process in the Unix environment.  That
level of multitasking, while powerful, isn't really of much use to most
business application developers, especially if they aren't writing UI or
communications code.

On the other hand, show me an easy to learn, widely accepted strategy for
writing parallel processed applications, and then you'll have an argument
for using Threads for something other than event drivers.

By the way, we had this "thread" stuff a LONG time ago.  It was called a
task, and there was a whole operating system built arond it, called EDX, the
Event Driven Executive.  EDX was written in a high-level language called
EDL, and was designed to be modified in the field by the end user.  This
machine processed dozens of devices simultaneously, and at the same time had
a prodigious (for the time) disk capacity.  It also ran COBOL for
applications programming, and even supported voice touchtone input, all in
the late 70s.

That machine, of course, was the Series/1.  High-level language support of
multi-tasking isn't new.

Joe