Ситуация такая. 

Приложение использует стороннюю библиотеку в виде .jar файла. Данная библиотека имеет функцию, которая загружает и работает с классом, имя которого я ей передал параметром.

Всё работает замечательно кроме одного случая. Эта библиотека ставится другим софтом в lib/ext. И теперь библиотека из lib/ext не может найти мой класс, который я ей передаю как параметр в функцию. Удалить эту библиотеку из lib/ext и пользоваться своей копией нельзя.

Что можно предпринять?

Если класс есть в -classpath, то в общем случае он будет найден. Нет никакой разницы, где лежит библиотека, если она подгружает классы стандартным образом.
Так как это утверждение не работает, то предположу, что библиотека некорректно грузит переданный ей класс. Тогда нужно выяснить, в чем косяк библиотеки. Например, она может не использовать -classpath, а искать класс по некоторому, известному только ей пути.

А загрузить еще одну копию своим класслоадером можно?
Поже что причина в том, что раз библиотека загружена системным класслоадером, то им же и пытается грузить указанный класс. Ну а системному класслоадеру понятное дело, начхать на класпас.

Class Loader сначала опрашивает более высоких Class Loader'ов загрузили они класс или нет. Если да, то второй раз класс не будет загружаться. Можно создать свой Class Loader расширив существующий и перекрыть в нем метод опрашивания "высших сил", тогда он сможет загрузить класс повторно.

Разница есть. Jar`ики, которые лежат в lib/ext подгружаются системным класслоадером, который ищет классы только в lib/ext. Когда происходит загрузка нового класса из существующего, по-умолчанию используется тот-же класслодер, которым был загружен текущий класс. Отсюда он не может найти классы вне lib/ext.



Неплохой вариант.

Но пока решилось патчингом библиотеки из lib/ext (открытая библиотека), чтобы она использовала более низкий класслоадер при загрузке классов.

вопрос меня заинтересовал и я провел некоторый инвестигейшн 

вот что удалось выяснить:
1) системные класс грузятся BOOTSTRAP загрузчиком. Он же загружает библиотеки расширений из JAVA_HOME/lib/ext. Он не видит классы, указанные в -cp
2) классы приложения грузятся СИСТЕМНЫМ загрузчиком. Это тот, который можно получить ClassLoader.getSystemClassLoader() Соответственно, он видит -cp
3) был найден workaround для вашего случая. Он заключается в использовании параметра java.ext.dirs. Этот параметр указывает директории, где jvm должна искать библиотеки расширений. Соответственно, его можно использовать в нескольких вариантах:

 - задать этот параметр пустым -Djava.ext.dirs=  Тогда расширения грузится не будут (в том числе и из JAVA_HOME/lib/ext)
 - указать в нем стандартную директорию JAVA_HOME/lib/ext, а затем директорию, откуда библиотека должна загружать классы. для этого случая есть один нюанс: все классы должны лежать в .jar файлах, так как jvm подгружает только джары, которые лежат в этих директориях;

порядок путей в параметре jvm использует так как и в -cp -слева направо. то есть первыми будут загружены библиотеки, чей путь указан левее, далее повторно классы jvm, естественно, грузить не будет.
 При этом, естественно, все библиотеки расширений грузятся BOOTSTRAP загрузчиком и не видят -cp

Использование параметра выглядит примерно вот так:
java -Djava.ext.dirs=D:\projects\testClassLoader\testClassLoader\ext;c:\Java\jdk1.6.0_21\jre\lib\ext -cp target/classes testclassloader.TestModuleMain

Потенциальная проблема - расширения имеют бОльшие права, чем код, загруженный системным загрузчиком. Как бы чего не напортить.