Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / GUI / May 2006

Tip: Looking for answers? Try searching our database.

Swing/EDT - Static vs Instance?

Thread view: 
Knute Johnson - 25 May 2006 18:39 GMT
When Sun published the recommendation to create and modify all Swing
components in the EDT, I changed the way I write my GUI apps to mimic
the example in the Java Tutorial.  The Tutorial example does the GUI
creation in a static method called on the EDT from the main method.
Before this recommendation we all just extended JFrame and created our
GUIs in the constructor.  Using the static method required some changes
to the coding of things like action listeners.  None of them
insurmountable just different.  But why the static method?  Why couldn't
we just extend JFrame as usual and instantiate it on the EDT?  I'm not
sure why I didn't think of this before but somebody else's post on
another subject got me to thinking.  So I'm curious how others create
their Swing GUIs.  Do you follow the Tutorial, use the old method or
something else?

Thanks,

knute...

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

public class test7 {
    public static void createGUI() {
        JFrame f = new JFrame("test7");
        f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        f.setSize(200,200);
        f.setVisible(true);
        System.out.println(EventQueue.isDispatchThread());
    }

    public static void main(String[] args) {
        Runnable r = new Runnable() {
            public void run() {
                createGUI();
            }
        };
        EventQueue.invokeLater(r);
    }
}

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

public class test8 extends JFrame {
    public test8() {
        super("test8");
        setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        setSize(200,200);
        setVisible(true);
        System.out.println(EventQueue.isDispatchThread());
    }

    public static void main(String[] args) {
        Runnable r = new Runnable() {
            public void run() {
                new test8();
            }
        };
        EventQueue.invokeLater(r);
    }
}

Signature

Knute Johnson
email s/nospam/knute/

Thomas Hawtin - 25 May 2006 18:59 GMT
> When Sun published the recommendation to create and modify all Swing
> components in the EDT, I changed the way I write my GUI apps to mimic
[quoted text clipped - 9 lines]
> their Swing GUIs.  Do you follow the Tutorial, use the old method or
> something else?

You can still extend JFrame. That doesn't change. However, needlessly
extending classes has always been a terrible practice and remains so.

Tom Hawtin
Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Knute Johnson - 25 May 2006 19:33 GMT
> You can still extend JFrame. That doesn't change. However, needlessly
> extending classes has always been a terrible practice and remains so.
>
> Tom Hawtin

Tom:

I don't disagree but I often compare my code to code I see on these
lists and in books and think that I don't extend enough classes.  I
participated in another thread the other day concerning getters and
setters.  A large part of the reason for them being protection when the
class is extended.  I can understand a different view for API
development but production code, at least most of the code I've written,
will never be extended.  Extending classes several times reminds me of a
discussion I had with a fellow I was working for several years ago.  We
were writing some large C programs and he told me that it was not
considered good practice to use more than 5 levels of indirection.

Signature

Knute Johnson
email s/nospam/knute/

Thomas Hawtin - 25 May 2006 20:45 GMT
>> You can still extend JFrame. That doesn't change. However, needlessly
>> extending classes has always been a terrible practice and remains so.

> I don't disagree but I often compare my code to code I see on these
> lists and in books and think that I don't extend enough classes.  I

There's an awful lot of bad books out there. The vast majority of code
is appalling.

> participated in another thread the other day concerning getters and
> setters.  A large part of the reason for them being protection when the
> class is extended.  I can understand a different view for API

Really?

> development but production code, at least most of the code I've written,
> will never be extended.  Extending classes several times reminds me of a

That doesn't matter. The fact that it extends a leaf class unnecessarily
is good enough reason for it to be bad code.

> discussion I had with a fellow I was working for several years ago.  We
> were writing some large C programs and he told me that it was not
> considered good practice to use more than 5 levels of indirection.

Take it one level at a time.

Tom Hawtin
Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Oliver Wong - 26 May 2006 20:31 GMT
> Extending classes several times reminds me of a discussion I had with a
> fellow I was working for several years ago.  We were writing some large C
> programs and he told me that it was not considered good practice to use
> more than 5 levels of indirection.

   Why the magic number 5?

   The heuristic I usually use is to ask myself if class A has an "IS-A
relationship" with class B. That is, whereever anyone uses class B, would it
make sense to use class A instead? If so, then A should extend B. If not,
then not.

   So when I have code like "public class MyApp extends JFrame", I ask
myself, does it really make sense that where ever a JFrame could be used, I
could give a MyApp instead? The answer is usually no. MyApp *USES* a JFrame
in its implementation, but it is not, itself, a JFrame.

   - Oliver


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.