Displaying Gif animation in java

Inside your JFrame or whatever, use this :

Icon imgIcon = new ImageIcon(this.getClass().getResource("ajax-loader.gif"));
JLabel label = new JLabel(imgIcon);
label.setBounds(669, 42, 45, 15); // You can use your own values
frame.getContentPane().add(label);

Source : How to display an animated gif in java swing

Maybe you are trying to make an animation that is to be played just at the start of your application, without interfering the upcoming events or components. So you might want to give a try to splash screens. Read about it from here: http://docs.oracle.com/javase/tutorial/uiswing/misc/splashscreen.html

In the link above, it demonstrates the usage of a class named SplashScreen which is just derived from Frame class. So the mechanism is like that: you display a separate frame (splash screen, your animations go here) and after some time your main application is launched.

'ImageIcon' class allows you to load gif animations. I load the image with 'getResource()'. For doing this I normally us URL class to pass the file path. The path does not need to be necessary in a remote machine as the name URL may suggest.

URL url = this.getClass().getResource(path);
Icon myImgIcon = new ImageIcon(url);
JLabel imageLbl = new JLabel(myImgIcon);
component.add(imageLbl, BorderLayout.CENTER);

path will be the path of the gif inside of the class folder.

References: http://docs.oracle.com/javase/tutorial/uiswing/components/icon.html#getresource

You just have to free EDT thread of some heavy tasks and do them in a separate thread. In that case gif animation will work together with other processes running.

You might also create your application interface in a separate thread (yes yes, not inside the EDT) but only until you display it. Afterwards you have should make all changes inside the EDT, otherwise you might encounter a lot of problems.

You can also load more UI elements in a separate thread later, just make sure that you add them onto displayed frames/containers inside EDT - that is the most important thing.

Here is a small example of "heavy-like" interface loading:

public static void main ( String[] args ) throws InvocationTargetException, InterruptedException
{
    // Main window

    final JFrame frame = new JFrame ();

    final JPanel panel = new JPanel ( new FlowLayout ( FlowLayout.LEFT, 5, 5 ) )
    {
        public Dimension getPreferredSize ()
        {
            Dimension ps = super.getPreferredSize ();
            ps.width = 0;
            return ps;
        }
    };
    frame.add ( new JScrollPane ( panel ) );

    frame.setSize ( 600, 500 );
    frame.setDefaultCloseOperation ( JFrame.EXIT_ON_CLOSE );
    frame.setLocationRelativeTo ( null );

    SwingUtilities.invokeAndWait ( new Runnable ()
    {
        public void run ()
        {
            frame.setVisible ( true );
        }
    } );

    // Load dialog

    final JDialog load = new JDialog ( frame );

    JPanel panel2 = new JPanel ( new BorderLayout () );
    panel2.setBorder ( BorderFactory.createEmptyBorder ( 15, 15, 15, 15 ) );
    load.add ( panel2 );

    final JProgressBar progressBar = new JProgressBar ( 0, 100 );
    panel2.add ( progressBar );

    load.setModal ( false );
    load.pack ();
    load.setLocationRelativeTo ( frame );

    SwingUtilities.invokeAndWait ( new Runnable ()
    {
        public void run ()
        {
            load.setVisible ( true );
        }
    } );

    // Heavy task (takes approx. 10 seconds + some time on buttons creation) 

    for ( int i = 0; i < 100; i++ )
    {
        Thread.sleep ( 100 );

        final JButton button = new JButton ( "Button" + i );
        final int finalI = i;

        // Updating panel and progress in EDT
        SwingUtilities.invokeLater ( new Runnable ()
        {
            public void run ()
            {
                panel.add ( button );
                button.revalidate ();
                progressBar.setValue ( finalI );
            }
        } );
    }
}

As you can see - all the interface update operations are made in EDT, everything else runs inside the other thread.

Also notice that main thread is not EDT thread, so we can do something heavy there right away.

In some cases its not needed to display loaded parts of interface right away, so you can add them alltogether at the end of the "heavy" operation. That will save some loading time and will make the initialization code much more simple.

Brief explanation about EDT and what i said in the answer...

...it was something i found after working three years under Swing L&F and lots of Swing-based applications. I digged a lot of Swing sources and found a lot of interesting things that aren't widely known.

As you know - the whole idea of single thread for interface updates (its EDT in Swing) is about keeping each separate component visual updates (and its events) in a queue and perform them one by one inside that thread. That is needed mainly to avoid painting problems since every component inside single frame is painted to the single image that is kept in memory. The painting order is strict there so one component won't overwrite another on the final image. Painting order depends on the components tree that is created by adding some components or containers inside another container (that is a basic thing you do when creating any application interface on Swing).

To summ up - you must keep all visual updates (methods/operations that might cause them) inside the EDT. Anything else might be done outside the EDT - for example you can prepare the application interface outside the EDT (again, unless you add/remove/move component inside an already visible container).

Still there might be some internal problems with that in some very very very rare cases. There was a good discussion of that question a long ago here:
http://www.velocityreviews.com/forums/t707173-why-does-jdk-1-6-recommend-creating-swing-components-on-the-edt.html

To be short: since 6th JDK version Sun stated in docs that even Swing components creation should be done inside EDT to avoid possible problems. They might appear in some specific cases with heavy interfaces creation due to the events which occurs while the components are bing created.

Anyway, i'd say that in some cases you might create your interface outside the EDT to avoid loader/application being stuck. In other cases, when it doesn't matter if application is stuck for the interface creation time - you should use EDT. And i cannot say anything more specific since everything depends on your case...