Re: Self-configuring classes
On Aug 4, 12:47 am, Twisted <twisted...@gmail.com> wrote:
On Aug 4, 3:18 am, Owen Jacobson <angrybald...@gmail.com> wrote:
What about the first google hit for "swing event dispatch thread":
Now why, pray tell, would someone who already knows Swing's basics and
has programmed Swing apps for years perform the Google search you
suggest?
Plenty of reasons. Someone keeping up on their skills in the face of
new java releases might be perusing java blogs and usenet posts.
Someone might have encountered one of the ways manipulating Swing
objects from outside the EDT can cause problems and be wondering why.
Someone might be having, well, this exact conversation and wondering
if more information was available somewhere.
If I had something I wanted to do that was new to me and involved
Swing I might perform such a search. If I'm typing a code snippet from
perfectly good memory of what I already know, why would it occur to me
to perform a search at all? Just in case something has been changed by
Sun?
Well, several Java revisions have come out since you started posting
here. For any random API it's likely at least one of those updates
changed something in it.
Programming, for better or for worse, doesn't happen in a vacuum. The
"best" way to do something may or may not be the way you or I or
anyone else did it last year, and today's "best practice" may be
superceded by something better (simpler, faster, easier to debug, or
more flexible) in the future. A five- or ten-minute docs refresher on
the tool at hand often pays off in the long run.
Are you therefore suggesting that all of us perform that specific
search every single day just in case Sun has decided to change
something about Swing's functionality on that particular day? And how
many other searches should we spend minutes on each and every day,
pray tell? Another one regarding the I/O classes I suppose, and
another for the collection classes ...
Ironically, Java 5 *did* update Collections. People who picked one
way and stuck with it back in Java 1.2 or 1.4 and stuck with it may
have been rudely surprised when their newly-updated compiler started
emitting warnings they'd never heard of before.
It's the developer's responsibility to check which parts of the API
changed when a new version of Java is released -- Sun publishes that
information in the form of release notes and changelogs.
In JavaSE 6, a lengthy note was added to the API documentation
without fanfare
You're right. They dropped the ball by forgetting to mention what
amounts to a documentation clarification in the release notes. Given
Sun's history of only including the highlights in the release notes
proper, though, it's fairly wise to check API docs for features are
mentioned in the notes after a release to see if anything else has
changed. The package docs are part of the documentation, no matter
how rarely you personally refer to them.
The SwingUtilities class is in the package javax.swing, and is
provided as part of the Java Standard Edition platform at least as of
Java 1.3; you'd have to check the API docs yourself to see if it was
available earlier than that.
Maybe it was SwingWorker that was third-party. Some SwingSomething is,
anyway, and I seem to recall it being mentioned in conjunction with
SwingUtilities a lot if it wasn't itself SwingUtilities.
Would it help if future posts used fully-qualified names or had import
statements? :-)