|The potential is there, yes.
The 1st issue is one of confusion for the human (not the JVM).
If you do run into a problem, you might be forced to question which class file
is being used.
Consider removing that confusion to more easily solve the problem by having
your class be in one place or the other... not both.
The 2nd issue has to do with ClassLoaders and how they work in Java.
To illustrate what we mean, we'll use SE bug #463 (which isn't really a bug
in SE at all).
That bug is entitled:
ClassCastException occurs when looking up a configured DataSource via JNDI
Here is a portion of that bug's description, which illustrates one situation where having a class file in both the main
SE classpath and also in a web-app's lib or classes folder can cause problems:
This problem is caused by the fact that a Container-wide DataSource that
has been configured via the ServletExec Admin pages is loaded into the JVM
using the System Classloader. The class file for such a datasource must be
placed onto the main SE classpath. If you have web app code which tries to
cast the DataSource object, *AND* that web app code can find the casting type
within the web app (in the classes folder, or the lib folder of the web app)
then the custom classloader for that web app is used to load the casting type.
An object loaded by classloader A cannot then be cast to an object of the
same type that was loaded by ClassLoader B.
In addition you should also be aware of FAQ #96 which tells of another location that the
JVM might be picking up a class file.
Yet another example of a problem that might be seen in this sort of situation would be if a webapp contained JSTL classes (which are already included with SE). The folllowing sort of error might be seen at runtime:
java.lang.LinkageError: Class javax/servlet/jsp/el/ExpressionEvaluator violates loader constraints
This may be due to version differences between the JSTL classes in the webapp and the JSTL classes that come with SE (which are in the main SE classpath). Or it may have nothing to do with version differences and simply be due to a classloader limitation as described above in this FAQ.