Re: Outside of the EDT: JOptionPane.showMessageDialog
John B. Matthews wrote:
(Stefan Ram) wrote:
public class Main
{ public static void main( final java.lang.String[] args )
{ final javax.swing.JFrame frame = new javax.swing.JFrame( "Hallo Sw=
ing!" );
frame.setDefaultCloseOperation( javax.swing.JFrame.EXIT_ON_CLOSE );
frame.setVisible( true ); }}
It hurts somewhat to see this, but this example appears
For two reasons.
I respect Stefan's knowledge, logic and code, but not his layout.
He's explained his reasons and I accept them. From him.
But don't agree. Like as if it mattered whether I do or not.
Pedagogically his style is useful, as it gives a contrast between
idiosyncratic and conventional styles, and students / interested parties
may make their own determination as to the relative merits.
just after the introduction of =BBnew=AB, and makes the effect
of =BBnew=AB visible somehow, so I thought it might be a good
motivation. In a sense, a JFrame is a =BBvisible object=AB, so
this example visualizes objects, which might help to learn.
But I have not yet introduced interface implementations, and
so I cannot yet implement java.lang.Runnable.
Pedagogical purposes often include introduction of flawed code for a
later twist. I heard an economics professor explain once how "guns and
butter" didn't make actual real-world sense, of course, but was important
to provide common ground and to introduce the terminology and techniques
of economic analysis. Analysis of the limitations of introductory models
is a standard way to grow a student's skills.
This seems like a reasonable compromise. When returning to the
topic, the example is simple enough to trace execution and show
that, while a particular implementation may be thread-safe,
Or you could go with John's more succinct and accessible way of saying
what I just rephrased.
there is no general assurance without starting on the EDT. The
didactic problem is complicated by the fact that incorrect
examples rarely fail reliably, and examples that fail reliably
are often so contrived as to to be obviously incorrect.
Two great points to bring to young minds' attention early on.
It also helps to introduce the notion of exogenous factors. The point
is that no factor can truly be ruled out as irrelevant. Many threading
bugs, in particular EDT ones and the change of Swing docs to reflect this,
were not recognized until the generalized shift to multiprocessor mobos
in the early oughts. This exposed both the blooms and the thorns of the
foresightful Java concurrency rose garden.
You might think the JVM insulates one from the exigencies of hard hardware.
Turns out you cannot ignore context entirely.
Another good thing to remark during early training.
--
Lew