Java Threads mailing list archive
New Swing Library (JFC)
From: Richard Beton <rdb@roke.co.uk>
Date: Thu, 02 Apr 1998 17:30:44 +0100
--------------319332773F0EE680E8B18ECC
Content-Type: text/plain; charset="us-ascii"
The new Java Foundation Classes (codename Swing) strongly discourage the
use of multi-threaded GUI programming. Quoting from one source
(http://java.sun.com:80/products/jfc/swingdoc-archive/threads.html)
It is our basic belief that extreme caution is
warranted when
designing and building multi-threaded
applications,
particularly those which have a GUI component.
Use of
threads can be very deceptive. In many cases
they appear to
greatly simplify programming by allowing
design in terms of
simple autonomous entities focused on a single
task. In fact in
some cases they do simplify design and coding.
However, in
almost all cases they also make debugging,
testing, and
maintenance vastly more difficult and
sometimes impossible.
Neither the training, experience, or actual
practices of most
programmers, nor the tools we have to help us,
are designed
to cope with the non-determinism. For example,
thorough
testing (which is always difficult) becomes
nearly impossible
when bugs are timing dependent. This is
particularly true in
Java where one program can run on many
different types of
machines and OS platforms, and where each
program must
work under both preemptive or non-preemptive
scheduling.
As a result of these inherent difficulties, we
urge you to think
twice about using threads in cases where they
are not
absolutely necessary. However, in some cases
threads are
necessary (or are imposed by other software
packages) and
so subArctic provides a thread-safe access
mechanism. This
section describes this mechanism and how to
use it to safely
manipulate the interactor tree from an
independent thread.
It is interesting to consider this strategy in the light of experience
gained from occam. Whilst occam totally lacks the carefully designed
library support of the JFC and the JDK, it does in principle allow
straightforward multi-threaded GUI programming. Coping with
non-determinism is a normal part of the occam design process, not the
insurmountable issue faced by users of the JFC.
Perhaps a sensible approach is to use JavaPP channels to dissociate
Swing GUIs from the underlying core application.
--
Richard Beton B.Sc. C.Phys. M.Inst.P.
Roke Manor Research Limited
--------- Standard Disclaimer about my own views etc etc --------
--------- My mail client accepts rich text (HTML) mail --------
Welsh Highland Railway: http://www.whr.co.uk/WHR/WHR.html
Java: In a world without Fences, who needs Gates?
--------------319332773F0EE680E8B18ECC
Content-Type: text/html; charset="us-ascii"
<HTML>
The new Java Foundation Classes (codename Swing) strongly discourage the
use of multi-threaded GUI programming. Quoting from one source (<A HREF="http://java.sun.com:80/products/jfc/swingdoc-archive/threads.html">http://java.sun.com:80/products/jfc/swingdoc-archive/threads.html</A>)
<P><I>
It is our basic belief that extreme caution is warranted when</I>
<BR><I>
designing and building multi-threaded applications,</I>
<BR><I>
particularly those which have a GUI component. Use of</I>
<BR><I>
threads can be very deceptive. In many cases they appear to</I>
<BR><I>
greatly simplify programming by allowing design in terms of</I>
<BR><I>
simple autonomous entities focused on a single task. In fact in</I>
<BR><I>
some cases they do simplify design and coding. However, in</I>
<BR><I>
almost all cases they also make debugging, testing, and</I>
<BR><I>
maintenance vastly more difficult and sometimes impossible.</I>
<BR><I>
Neither the training, experience, or actual practices of most</I>
<BR><I>
programmers, nor the tools we have to help us, are designed</I>
<BR><I>
to cope with the non-determinism. For example, thorough</I>
<BR><I>
testing (which is always difficult) becomes nearly impossible</I>
<BR><I>
when bugs are timing dependent. This is particularly true in</I>
<BR><I>
Java where one program can run on many different types of</I>
<BR><I>
machines and OS platforms, and where each program must</I>
<BR><I>
work under both preemptive or non-preemptive scheduling.</I><I></I>
<P><I>
As a result of these inherent difficulties, we urge you to think</I>
<BR><I>
twice about using threads in cases where they are not</I>
<BR><I>
absolutely necessary. However, in some cases threads are</I>
<BR><I>
necessary (or are imposed by other software packages) and</I>
<BR><I>
so subArctic provides a thread-safe access mechanism. This</I>
<BR><I>
section describes this mechanism and how to use it to safely</I>
<BR><I>
manipulate the interactor tree from an independent thread.</I>
<P>It is interesting to consider this strategy in the light of experience
gained from occam. Whilst occam totally lacks the carefully designed library
support of the JFC and the JDK, it does in principle allow straightforward
multi-threaded GUI programming. Coping with non-determinism is a normal
part of the occam design process, not the insurmountable issue faced by
users of the JFC.
<P>Perhaps a sensible approach is to use JavaPP channels to dissociate
Swing GUIs from the underlying core application.
<BR>--
<BR>Richard Beton B.Sc. C.Phys. M.Inst.P.
<BR>Roke Manor Research Limited
<BR>--------- Standard Disclaimer about my own views etc etc --------
<BR>--------- My mail client accepts rich text (HTML) mail
--------
<BR>Welsh Highland Railway: <A HREF="http://www.whr.co.uk/WHR/WHR.html">http://www.whr.co.uk/WHR/WHR.html</A>
<BR>Java: In a world without Fences, who needs Gates?
<BR> </HTML>
--------------319332773F0EE680E8B18ECC--
Last updated: Tue Nov 2 12:11:36 1999
Maintained by Peter Welch.