Однажды я делал несложный сервлет и, соответственно, менял его реализацию.
После этого в новые классы копировались в WEB-INF/lib/classes (с сохранением структуры каталогов) и обновлялся тайм-штамп дескриптора контекста или web.xml при автоматическом развёртывании.
Остальное делал сервлет-контейнер (Tomcat).
Понятно, что это не хот-патч, но вполне себе оперативное развёртывание.
В случае war-файлов контейнеры позволяют использовать их распакованный вариант. Это, конечно, не по стандарту, но, вроде как, общепринятая фича, которая сильно ускоряет обновление и перезапуск приложения.
Это я всё к тому, что, может быть, проще надо быть?

questionerведь по стандарту если мы меняем jsp, то контейнер на лету должен отразить наши изменения, а jsp ведь это сервлет, то есть есть class файл.Не совсем.
Если говорить о tomcat, то сервлет-контейнер проверяет изменения jsp-файлов тогда и только тогда, когда находится в режиме разработки (по умолчанию). Но эту фичу можно выключить в web.xml и тогда, после первого обращения, перекомпиляции происходить не будет.
Все скомпилированные классы находятся в отдельном временном каталоге. Если в каталоге появилась новая реализация, а старый класс был выгружен сборщиком мусора - новый вариант загрузится автоматически, когда вновь потребуется.

questionerну вообще хотелось бы апрувЧего?
Того, что jsp-компиляются в временный каталог? Достаточно один раз туда заглянуть.
Или моих измышлений на тему когда происходит загрузка? Так, вроде, везде указано, что JVM грузит классы по запросу, а не при старте. Нет запроса - нет и загрузки. Ну а сами запросы могут быть из разных неожиданных мест.

questionerно раз вопрос встал, то хочется каких-то серьезных доказательствВсё, о чём я написал подробно прокоменнтировано в web.xml этого самого tomcat. Доступно для изучения, проверки и всё такое прочее.Но и про основную тему - написать простейший hot deployer прошу остальных людей читающих эту тему не забывать.Самый простой вариант - ничего не делать.
Нет, как правило, такой задачи - "оперативная замена".
Есть, как правило, задача "минимизировать даун-тайм при обновлении приложения".
Простейший вариант - работать с распакованным war.
В том же tomcat, в актуальной седьмой версии, реализован механизм параллельного развёртывания.
Если две версии одного приложения не конфликтуют между собой, то они могут быть развёрнуты параллельно.
При этом контейнер будет направлять все "новые" запросы на новую версию, а после того, как отработают все "старые" запросы - "свернёт" старую версию, после чего её можно будет спокойно удалить.