threads - use them as much as you can

[Sean Hinde]

Uffe,

>(Which doesn't really help me now that I am honestly trying to get
>into Java programming for GUIs.)

I sympathise. It looks like Ericsson's new "Service Creation Environment"
for Intelligent Networks will require us to write service logic in Java
(there's no GUI!). Also the JAIN initiative from Sun seems likely to adopted
by the 3gpp standards group as their standard service creation API. You
never know, by next year I may be trying to peddle the old "non programmer"
writes IN service in Java myth :-) (Actually - no, never again!).

>Seriously, though (even though it _was_ a serious yawn), the makers of
>Java got concurrency wrong from the start. Trying to fix it later
>while maintaining backward compatibility is going to be a real
>challenge.

Agreed, but there appears to be a serious amount of will power and
resourcing behind this. At the moment attempting to write anything
asynchronous and multithreaded seems to be extremely painful because the
Java language and runtime provide only hindrance. If the platform is fixed
sufficiently to allow "normal" Java programmers to do this stuff safely then
maybe it will become the platform of choice for "responsive" non blocking
clients and servers..?

They have also included some things Erlang doesn't have which the "Hard Real
Time" crew use including:

*  Many thread priorities with timely pre-emption when higher priority
threads become runnable (e.g. by receiving an async message).

*  The ability to set a maximum possible runtime to be used by a thread
before the system kills it and notifies the initiator.

There might even be something we can learn from their work ;)

- Sean



NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.