OK, here we go. As promised, any errata found by readers will be fully attributed to them. :)

page 4: "What's more, the details of the garbage collection spec.... << Reference from JVMSpec here >>" What can I say? I missed a "TODO"-style tag in my final pass over the manuscript. At least now you have glaring proof that I'm just as human as the next writer.... :-) The reference in question, which should have been placed there, should be to section 3.5.3 of the Java Virtual Machine Specification: "The Java virtual machine assumes no particular type of automatic storage management system, and the storage management technique may be chosen according to the implementor's system requirements."
page 4, Footnote 4: "Although this isn't exactly true, as we'll see when we talk about the CompilerClassLoader in Chapter 2." Well, OK, I admit it, CompilerClassLoader doesn't get introduced until Chapter 3. Chapters 2 and 3 used to be one chapter.
page 52: The name of the class is chap02.Hello, while the text refers to it as com.javageeks.util.Hello. This class changed name several times during the development of the book, especially as I changed the way the code was structured on the filesystem while developing it. In fact, if you attempt to use the code exactly as written, the sample will fail--my ISP didn't like the idea of people executing a sample and finding my website every time. (They thought the load would be too great.) To make this example work, take the Hello.java file, compile it, and place it on a webserver to which you have write-access. Download Tomcat if you need to to get the webserver under your control. Now, place the Hello.class file somewhere in the browsable area of the webserver's directory tree, and point the URLClassLoader URL at it; the example should work for you at that point. Sorry about the confusion. (Thanks to Jim Femister for finding this problem.)
page 63-64: The code block says, at the end of main(), that the cast/assignment from the c.newInstance() call will fail when stored into the FileSystemClassLoader reference fscl, when in fact, it will succeed for this code sample--when the FileSystemClassLoader instance is asked to load the class, remember, it will delegate to its parent first, which in this case is AppClassLoader, the same class that loaded the FileSystemClassLoader instance in the first place. IF, however, the FileSystemClassLoader class were loaded under a different loader that didn't delegate to AppClassLoader, this cast would fail for the reasons cited in the text. If you want to see the exception, change the "parent" parameter in the FileSystemClassLoader constructor to be "null" (which means it delegates solely to the bootstrap ClassLoader), and you should see the Exception. (About all I can say on this egregious error is that I wrote the text while experimenting heavily with the delegation tree; I saw what I wanted to see when I ran the sample, and wrote the text accordingly. Thanks to Jian Liu and Yong Chen for catching it.)
page 235: The text mentions "the CD that comes with the book". No such CD was ever shipped with any printing of this book; the original intent was to do so, but cooler heads prevailed and instead we decided to make everything available off the Web.
page 187: The text mentions running the LocalServer class directly as a way of testing it, but the code itself has no such main() method. This is one of the casualties of the "evolving codebase" approach I took with the book--the main() method was removed once I'd finished testing it. :) It shouldn't be overly difficult to add one in and test yourself; if serious problems arise, don't hesitate to email me. (Thanks to Ranjan Bhattacharya for pointing out this and the p.235 errata.)
Charles Adkins wrote that "In LocalServer.java I find the following references [to the classes] EDU.oswego.cs.dl.util.concurrent.. My compile doesn't like this. Am I missing something (either in code or in understanding)?" Two issues arise out of this--first, you must have the concurrent library by Doug Lea mentioned in the text. I chose not to ship the concurrent.jar file as part of the standard download to keep the download size small and because I wanted you to hit his page to get the library, to avoid any ill will regarding licensing/redistribution. (He gets the credit for that library--it's simply too cool of a library to ignore the fact that it's his creation.) Secondly, your compiler may dislike the upper-case EDU prefix; early Java standards held that the package prefix DNS suffix (.com, .net, and so on) should be upper-cased, but that was dropped by the time JDK 1.1 was released. Some compilers, moreover, are case-sensitive on the package names and won't (as others will) recognize EDU.foo.Bar as the same class as edu.foo.bar. (I actually amended the concurrent.jar source to simply call the package "concurrent" for my "personal" code.)
Joseph P. Dougherty made me aware of two things:
1. "ConsoleControlService.java refers to com.javageeks.gjas.ConfigurationInfo which appears to have been renamed to ConfigProperties." Absolutely true, and written this way, will not compile.
2. "The TestService.java file (mentioned on pg. 223) is missing from the files provided on the website." Also true; I later coalesced TestService and HelloService into one service, but didn't update the TEST switch in the system proper. You can simply copy HelloService.java to TestService.java (renaming the classname, of course) to make it work.
Murali Therthala writes:
"In reading through the sections in chapter 4, I noticed something missing in PluinApp.java or you can correct me if I am wrong. Assume we do not have any Plugins at all initially. If we were to run the PluginApp, we would NOT see any plugins listed below the File menu option.
"Now lets drop the JAR file for the given PluginOne.java under the folder and hit the reload option under File. This should load the PlugInOne and display the PlugInOne under the File menu. The plugin gets loaded but the display does not appear.
"I was looking at the source code for PluginApp.java. There exists a method called createMenubar() where the menuitem "Reload" gets added to the File item as show below.
```
    mi = new JMenuItem("Reload");
    mi.addActionListener(new ActionListener()
    {
        public void actionPerformed(ActionEvent e)
        {
            pluginCL.reload(".",getPluginListener());
        }
    });
    
```
"I would change the above segment as shown below.
```
    mi = new JMenuItem("Reload");
    mi.addActionListener(new ActionListener()
    {
            public void actionPerformed(ActionEvent e)
            {
                pluginCL.reload(".",getPluginListener());
  
                // Allow the Plugins to register themselves
               doPlugins(new PluginAction()
               {
                   public void action(Plugin plugin)
                   {
                       plugin.addToMenuBar(mb);
                   }
            });
        }
    });
    
```
"This would ensure that the newly added plugins are displayed in the menu."

He's absolutely right--the menu's action handler does the reload of the plugins themselves, but never gives the plugins a chance to register themselves with the menubar. Good catch.