Comments

any feedback regarding the use of JavaDoc style comments is welcome.

The structure of your method comments is:

/** methodName - what method does */

But JavaDocs are actually structured like this:

/**
 * short description of what method does.
 * <p>
 * Longer description, special cases, etc.
 * 
 * @param paramName what param does
 * @param anotherParam what it does
 * @return what is returned
 */

The important parts are that the method name should not be part of the comment (it will be added automatically when generating a JavaDoc), and that there are annotations for method arguments and return values. You can also add additional annotations.

Many of your in-code comments are a bit redundant, for example lettersGuessed: letters the user has guessed.

Structure

• Information is a very generic name. What information? It seems to just contain everything where you were unsure of where to put it: It contains the alphabet, the words, the user input, etc. I would split this up into different classes. I do see why you did this though: So that the GUI can get one object, from which it then can obtain state to be presented. Instead of creating one god object which contains all the information, you could instead add parameters to the GUI methods, and pass the information to them that way (eg drawLettersGuessed() -> drawLettersGuessed(Set<Character> guessedLetters)).
• Your Logic class also does a bit too much: It handles the game state (updateSecretWord, isGuessValid, etc), but also the game loop (eg playAgain).
• your GUI on the other hand is structured quite well, with the separation of DrawingPanel and the general GUI.

Misc

• use the explicit private/public keywords instead of the default.
• the WordReader always has to read a file, right? Otherwise it's useless. So I would add a constructor and read the file when constructing it.
• size() != 0 can be written as !isEmpty().

Comments

any feedback regarding the use of JavaDoc style comments is welcome.

The structure of your method comments is:

/** methodName - what method does */

But JavaDocs are actually structured like this:

/**
 * short description of what method does.
 * <p>
 * Longer description, special cases, etc.
 * 
 * @param paramName what param does
 * @param anotherParam what it does
 * @return what is returned
 */

The important parts are that the method name should not be part of the comment (it will be added automatically when generating a JavaDoc), and that there are annotations for method arguments and return values. You can also add additional annotations.

Many of your in-code comments are a bit redundant, for example lettersGuessed: letters the user has guessed.

Structure

• Information is a very generic name. What information? It seems to just contain everything where you were unsure of where to put it: It contains the alphabet, the words, the user input, etc. I would split this up into different classes. I do see why you did this though: So that the GUI can get one object, from which it then can obtain state to be presented. Instead of creating one god object which contains all the information, you could instead add parameters to the GUI methods, and pass the information to them that way (eg drawLettersGuessed() -> drawLettersGuessed(Set<Character> guessedLetters)).
• Your Logic class also does a bit too much: It handles the game state (updateSecretWord, isGuessValid, etc), but also the game loop (eg playAgain).
• your GUI on the other hand is structured quite well, with the separation of DrawingPanel and the general GUI.

Misc

• use the explicit private/public keywords instead of the default.
• the WordReader always has to read a file, right? Otherwise it's useless. So I would add a constructor and read the file when constructing it.
• size() != 0 can be written as !isEmpty().
• instead of just crashing when the word file doesn't exist or is empty, an informative error message would be nice (Could not find file /path/to/file/filename and File /path/to/file/filename is empty or malformed).