Egor

Очевидно, ему не нравится, что в переменной g нет объекта. Читаем описание метода getGraphics:

This method will return null if this component is currently not displayable.

Enterprise разработка - это разработка, направленная на решение проблем бизнеса. В отличии от разработки для решения проблем конечных пользователей.

На самом деле нет каких-то зафиксированных принципиальных характеристик, которые присущи только EA. По-этому, в разговорной речи понятие "энтерпрайз" может значить весьма разные вещи. С одной стороны энтерпрайз - не про увлечение модой с переписыванием всего, как только появится новый тренд. Ибо это _дорого_, так как цена ошибки дорога. С другой стороны - совсем не обязательно, что это 20-летние технологии. Конкретный бизнес сам для себя выбирает модели развития и обновления стека технологий. С одной стороны - это сложность ПО, бизнес-логики. С другой - сложность понятие весьма относительное.

Но если все же пытаться выделить какие-то характерные черты, я бы назвал несколько:
* устойчивость к трендам (использование их, когда они пройдут стадию моды и перейдут к стадии заинтересованности крупными игроками, ибо никому не нужны технологии, которые через год умрут и их поддержка будет дорожать каждый день).
* сложная и непостоянная бизнес-логика, давление на нее из множества источников
* результат сложной переменчивой бизнес-логики в совокупности с длительным использованием продукта приводит к целям снижения стоимости поддержки за счет стоимости первоначальной разработки, производительности и потребляемых ресурсов. ООП, SOLID, Unit Test/TDD, DDD - все эти популярные буквы - последствия "энтерпрайза", когда мы готовы серьезно подходить к написанию кода для облегчения его последующего изменения.
* слабо заметный вклад конкретного программиста, проистекает из сложности ПО

Требования к программисту... ну я бы сказал, усидчивость, вдумчивость, исполнительность... хм, а что, в каких-то других областях другие требования к программистам? Хотя, конечно, в противоположность, можно назвать способ разработки "быстро-быстро и в продакшн". Но, к слову, такие ситуации могут и в энтерпрайзе возникнуть.

По-этому, стоит рассматривать не энтерпрайз/не энтерпрайз, а конкретные компании с конкретными требованиями и циклами разработки.

JPA - это интерфейс языка JAVA, не имеющий реализации в самом языке. Если просто добавить аннотации JPA в свои классы, то не произойдет ровным счетом ничего. Для того, чтобы аннотации начали "работать", следует развернуть и настроить в проекте фреймворк, который "найдет" все классы с JPA-аннотациями и "состыкует" их с сущностями СУБД. Этим фреймворком у вас является Hibernate.

По поводу "работать с hibernate можно и через JPA или отдельно от него" - тут в основном дело вкуса. У вас есть два варианта сообщить Hibernate какие классы "замапить" на таблицы БД:
1. Добавить в классы аннотации JPA
2. Создать XML-файлы, в которых будет описано сопоставление классов объектам БД.

По доступной функциональности оба метода равны между собой, при этом аннотации JPA более современны. Я бы рекомендовал JPA, т.к. при открытии класса сразу будет видно, что он "замаплен", а в случае использования XML, "замапленный" класс визуально неотличим от других классов.

Чё толку изучать врэймворк и не понимать по каким принципам он робит? Изучи JavaEE, ставь себе задачи (хоть может они и будут казаться примитивными), и пытайся их реализовать и через Spring и через JavaEE.