NFJS COSS 2008 1st Day Wrap Up

It is the morning after the first day of the No Fluff Just Stuff Central Ohio Software Symposium 2008 and I am writing this blog at 6:05 am because I am still so mentally stimulated I could not sleep at all last night so I gave up trying. I hope it does not catch up with me during today's sessions.

I really enjoyed Jared Richardson's, author of Ship It! A Pratical Guide to Successful Software Projects, keynote called Career 2.0. He announced he was writing a book of the same name that he expects to finish in January. In his keynote, he encouraged us to take control of our careers by improving our visibility in the industry. Some of his suggestions for getting started were writing, speaking and contributing to open source. He recommended setting goals but starting with simple steps like writing a blog, giving lunch and learns in your office or contributing documentation to your favorite open source project or maybe one you want to learn more about.

I have to agree with Jared completely. During my exit interview from college with my advisor, I was asked what I wanted to do with my career. I told her I don't know. But I did know there were two things I did not want to do. I did not want to write and I did not want to teach. 12 years, 4 books, several articals, numerous technical classses, many conferences and COJUG presentations I can say that was a very narrow minded view. I have found those are two of my favorite things to do and doing them have opened so many doors including free trips to Europe. I also discovered that contributing and observing open sources has really improved my disipline as a developer. It has allowed me to be exposed to more projects and practices then I could even be exposed to in my consulting practice. It allows me to see more of what works and what doesn't.

I also attended Scott Davis's, author of Groovy Recipes, Blue Pill and Red Pill presentations I had heard so much about from Java One. I was not dissappointed. I think it was a great introduction to Groovy for Java developers.

Tip: Causes of java.lang.ClassNotFoundException

Class loading issues are a common frustration for many Java developers. The dreaded java.langClassNotFoundException means they can forget about going home at a reasonable hour. While Java class loading is very powerful feature, it is also a very flexible and confusing feature. But don’t let this exception scare you. The majority of the time, there are three very practical things to look at in order to resolve the issue.

1. If you are loading a class by name either using Class.forName() or an Inversion of Control container like Spring it may be as simple as the class name was spelled incorrectly. Validate the fully qualified class name is spelled correctly. The best way is to use the Eclipse “Copy Qualified Name” feature or copying and pasting the package name and class name directly from the source file.
2. The mostly likely culprit is the class can not really be found. This can be caused by the directory or jar file containing class not being included in the JVM classpath. The other common cause when multiple class loaders are involved such as in a web container or application server is a visibility problem. For example classes in an ejb-jar do not have access to classes in the war file for the majority of application servers. But classes in the war file have access to classes in the ejb-jar. The reason is the war file typically has its own class loader which is a child class loader of the ear class loader. The basic rule is children class loaders have access to their parents but not visa versa. For this error, check your application server’s class loading documentation and make sure the class that is trying to access the not found class has the acceptable access.
3. The most challenging cause to debug is a dependency issue during initialization of a class. During initialization if a class can’t find certain resources it depends on such as other classes or files, this may result in a ClassNotFoundException. To resolve this, you may need to validate all dependencies are available. If you have the code, you can look at the class imports and any static initilization. If you don’t, you might need to reverse engineer the class to determine the dependencies.
   

I hope this helps. Just remember the cause of ClassNotFoundExceptions can be difficult to resolve but they are always deterministic so stick with it.