The difference from the Java API Specifications is as follows.
For ClassNotFoundException
:
Thrown when an application tries to
load in a class through its string
name using:
- The
forName
method in class Class
.
- The
findSystemClass
method in class ClassLoader
.
- The
loadClass
method in class ClassLoader
.
but no definition for the class with
the specified name could be found.
For NoClassDefFoundError
:
Thrown if the Java Virtual Machine or
a ClassLoader
instance tries to load
in the definition of a class (as part
of a normal method call or as part of
creating a new instance using the new
expression) and no definition of the
class could be found.
The searched-for class definition
existed when the currently executing
class was compiled, but the definition
can no longer be found.
So, it appears that the NoClassDefFoundError
occurs when the source was successfully compiled, but at runtime, the required class
files were not found. This may be something that can happen in the distribution or production of JAR files, where not all the required class
files were included.
As for ClassNotFoundException
, it appears that it may stem from trying to make reflective calls to classes at runtime, but the classes the program is trying to call is does not exist.
The difference between the two is that one is an Error
and the other is an Exception
. With NoClassDefFoundError
is an Error
and it arises from the Java Virtual Machine having problems finding a class it expected to find. A program that was expected to work at compile-time can't run because of class
files not being found, or is not the same as was produced or encountered at compile-time. This is a pretty critical error, as the program cannot be initiated by the JVM.
On the other hand, the ClassNotFoundException
is an Exception
, so it is somewhat expected, and is something that is recoverable. Using reflection is can be error-prone (as there is some expectations that things may not go as expected. There is no compile-time check to see that all the required classes exist, so any problems with finding the desired classes will appear at runtime.
If you're doing this out of curiosity and to learn something new, rather than to meet specific requirements for a specific project, maybe you'll enjoy the Play! Framework. It contains a lot of stuff from other frameworks and is designed to get you up and going very quickly, with short development cycles and not a lot of arcanae.
Their stated purpose is to be "by Web developers for Web developers". They intend to put the fun back into Web programming.
This sounds good and I've read a few nice things about it in fora and blogs, but I haven't tried it myself yet so that's all the recommendation I can give.
Best Answer
Client-side validation (assuming by "client-side" you mean javascript-based) is a myth. It makes for a nicer UI - no question - but it can't be called "validation" because anything that comes from the client can not be assumed valid; not until it's validated on the server.
Server-side validation is not a monolithic piece either - there are at least 3 components to it:
It's possible to derive #1 from #2 - Hibernate Validatior does an excellent job at that assuming you're using Hibernate as your JPA provider.
It's also possible to derive client-side checks from #3. If you intend to use GWT then using GWT VF recommended by Jeff is a good approach as it's based on the same spec (JSR-303) as Hibernate Validator. If you're going to use something else, it's reasonably straightforward to write code generating necessary scriptlets from either annotations or XML-based validation rules. I've done it for ExtJS controls in the past.
The biggest problem is bridging #2 and #3 - the same domain entity may be represented by many different views in UI, each with their own validation rules; said validation rules may be conditional upon entity state and change dynamically, etc... AFAIK there's no good way to do it automatically unless your UI is of very simplistic 1-to-1 CRUD type.