Re: threads and GUIs
Lew wrote:
Class names by convention should begin with an upper-case letter.
LC's No-Spam Newsreading account wrote:
I thougt the "main" class in an application should have the same name as
Not just the "main" class but all public classes need to have the same
basename as the class name, in typical file system-based source /
class trees. Thus the bytecode for class "FooBar" would be in a file
"FooBar.class".
By convention, type, method and variable names are spelled in camel
case with an initial upper-case letter for types and an initial lower-
case letter for variables and methods. The exception is constants,
which are spelled in all upper case.
These conventions have been in place since Java first started getting
popular and are well documented on java.sun.com:
<http://java.sun.com/docs/codeconv/index.html>
There's some wiggle room on things like opening-brace placement,
indentation and how to capitalize intialisms like "URL", but the bulk
of the conventions are pretty universally and rigorously followed.
the .java [sic] source file. I use upper case (camel case) for directorie=
s.
Directories correspond to package names. By convention, not quite as
firm as other naming conventions, packages, and thus directories, are
spelled with all lower-case letters.
Lew wrote:
Don't start threads from constructors.
LC's No-Spam Newsreading account wrote:
I do not want to. I'm not even sure a standalone application like this
needs a constructor (see reply to other message). Anyhow I have the same
Every successfully compilable class needs and in fact has a
constructor whether you write one or not.
problems using a constructor, or using a plain method.
That doesn't mean that starting threads from a constructor is a good
idea. It just means that you have a different bug, which others in
this thread have already addressed.
Lew wrote:
All that 'dummy=null' stuff is highly suspicious, too.
LC's No-Spam Newsreading account wrote:
That was just a blind attempt. I thought that if I did a repeated
dummy=new monitor(); I could incur in memory leaks.
Blind attempts to fix problems tend to bump into walls. Why did you
think that pointing the 'dummy' reference to different instances would
incur memory leaks?
Remember that I have a "break" button which should terminate the threads
started by monitor(). It does a tsw4.interrupt(); Monitor catches this
and terminates.
Then another "restart" button should execute monitor() again. Since it
is this which gives the error on the thread state, I thought may be it
had not yet disposed properly of the old monitor().
As others have stated, you cannot restart a thread that has
terminated. That results in an 'IllegalThreadStateException '.
Anyhow the current version has no constructor and no dummy. Just calls
monitor();
and gives the same problem
You say that as if we could somehow magically read your mind to know
what's in or not in your code.
Do not ignore <http://sscce.org/>, previously recommended. How do you
expect anyone to give meaningful answers when you don't give any
relevant details?
GIGO: Garbage in, garbage out. If you don't give good data, you can't
get good answers.
--
Lew