[Jacob]

This is the source code for a runescape loader. In short it grabs the most current jar from runescape.com, loads it into a gui as an applet, and loads the game through the gui.

Everything is here at this github link, tomorrow I'll be heavily commenting the code for people who need help with it all.

Please let me know what can improved btw!

https://github.com/oneluckyducky/RunescapeLoader

[Deque]

Thanks for the code, Jacob. That's a good example for a loader.

I looked at the source and I miss the usage of invokeAndWait() int the initial thread to prevent concurrency problems.
It would be like this in your main:

Code:

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

The reason is stated here:

Every program has a set of threads where the application logic begins. In standard programs, there's only one such thread: the thread that invokes the main method of the program class. In applets the initial threads are the ones that construct the applet object and invoke its init and start methods; these actions may occur on a single thread, or on two or three different threads, depending on the Java platform implementation. In this lesson, we call these threads the initial threads.

So they are run in different threads, but Swing isn't threadsafe. Because of that bugs due to concurrency problems are possible if not run by invokeAndWait or invokeLater. These errors may or may not occur. The smaller the project, the least often you get these weird bugs in my experience.

Further read: http://docs.oracle.com/javase/tutorial/u...index.html

The way you handle updating the label to show the progress is unusual and probably won't work anymore if you add invokeAndWait to your main.
Usually the Swing GUI will freeze, if you do a task that takes very long, which is i.e. downloading the jar and loading the classes in your code. Because of that you use the SwingWorker to perform long tasks instead of doing it right away in the Event Dispatch Thread. The SwingWorker is a kind of thread designed to be used with Swing. PropertyChangeListener can listen for the progress and so you are able to display the progress.

Thanks again for your share. I love to see more code on HC.

Deque

[Jacob]

Thanks for your comments Deque! I didn't use anything from SwingUtilties because I everything is running on a single thread, so I figured there was no issue with concurrency. Usually I do use SwingUtilities though.

Although, I have a question that even Java Docs can't answer properly. What is the real difference between SwingUtilties.invokeLater and SwingUtilities.invokeAndWait?

[Deque]

Thanks for your comments Deque! I didn't use anything from SwingUtilties because I everything is running on a single thread, so I figured there was no issue with concurrency.

The tasks have to be scheduled on the EDT. If you don't start the GUI with invokeLater you might run into problems even if you don't use any threads by yourself (the JVM uses several threads though).
These kind of bugs are very hard to fix, because they occur only sometimes or only on some machines and you might waste a lot of time with finding the reason. It is sad that most Swing tutorials do this wrong.

Although, I have a question that even Java Docs can't answer properly. What is the real difference between SwingUtilties.invokeLater and SwingUtilities.invokeAndWait?

invokeLater schedules the tasks and returns, invokeAndWait does the same, but waits for the tasks to be finished and returns afterwards.
You use invokeAndWait for applets, so that the init method of that applet can not return before the GUI is created.