Что такое java enterprise
Java SE и Java EE: различия, характеристики и подробный обзор
Сегодня мы поговорим с в ами о том, какая разница существует между Java SE и Java EE — основных продуктов Java Oracle (Ява Оракл). Сама по себе технология разработки Ява — это совмещение 2-х компонентов внутри:
Язык программирования Java собрал в себе современность, объектную ориентированность, высокий уровень языка, особый синтаксис и собственный стиль.
Платформа Ява — это собственная среда для разработки, где работают программы, которые писались на языке программирования Java.
Среда разработки, чтобы программировать на языке Java
На данный момент есть всего 4 подобны х среды:
Java SE (Standar d Edition)
Среда Java SE вбирает в себя:
Java EE (Enterprise Edition)
Java ME (Micro Edition)
Java FX
Ява FX — это полноценная среда, которая часто применяется для создания функционального приложения с возможностью применения облегченного API. Программа на Java FX пользуется аппаратной, ускоренной графикой и медиа-движком, чтобы воспользоваться достоинством современного внешнего вида, ну и чтобы использовать производительность на максимуме.
В Java SE пишутся приложения, имеющие возможность запускаться как простые java-программы внутри самого контейнера. А в Java EE возможно делать то же самое, однако она еще предоставляет в ам более широкие возможности управления и возможность поточного масштабирования.
Если попытаться подытожить, то Java EE = Java SE + дополнительные библиотеки + наличие фреймворков + технологические спецификации, расширяющие ваши возможности управления. Вот и вся разница и все различия в данных продуктах Java Oracle (Ява Оракл).
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Введение в Java EE
Java EE — что это?
Развитие Java EE
Архитектура Java EE приложений
Уровни приложений
Клиентский уровень представляет из себя некоторое приложение, которое запрашивает данные у Java EE сервера (среднего уровня). Сервер, в свою очередь, обрабатывает запрос клиента и возвращает ему ответ. Клиентским приложением может быть браузер, отдельное приложение (мобильное либо десктопное) или другие серверные приложения без графического интерфейса.
Средний уровень подразделяется, в свою очередь, на web-уровень и уровень бизнес-логики.
Web-уровень состоит из некоторых компонент, которые обеспечивают взаимодействие между клиентами и уровнем бизнес-логики.
На web-уровне используются такие технологии Java EE:
Уровень бизнес-логики состоит из компонент, в которых реализована вся бизнес-логика приложения. Бизнес-логика — это код, который обеспечивает функциональность, покрывающую нужды некоторой конкретной бизнес сферы (финансовая индустрия, банковское дело, электронная коммерция). Данный уровень можно считать ядром всей системы.
Технологии, которые задействованы на данном уровне:
Уровень доступа к данным. Данный уровень иногда называют уровнем корпоративных информационных систем (Enterprise Information Systems, сокращенно —EIS). EIS состоит из различных серверов баз данных, ERP (англ. Enterprise Resource Planning) систем планирования ресурсов предприятия и прочих источников данных. К этому уровню за данными обращается уровень бизнес-логики.
В данном уровне можно встретить такие технологии, как:
Сервера приложений, контейнеры, компоненты
Контейнеры апплетов выполняются большинством браузеров. При разработке апплетов можно сконцентрироваться на визуальной стороне приложения, в то время как контейнер обеспечивает безопасную среду.
Контейнер клиентского приложения (ACC) включает набор Java-классов, библиотек и других файлов, необходимых для реализации в приложениях Java SE таких возможностей, как внедрение, управление безопасностью и служба именования.
Веб-контейнер предоставляет базовые службы для управления и исполнения веб-компонентов (сервлетов, компонентов EJB Lite, страниц JSP, фильтров, слушателей, страниц JSF и веб-служб). Он отвечает за создание экземпляров, инициализацию и вызов сервлетов, а также поддержку протоколов HTTP и HTTPS. Этот контейнер используется для подачи веб-страниц к клиент-браузерам.
EJB (Enterprise Java Bean) контейнер отвечает за управление и исполнение компонентов модели EJB, содержащих уровень бизнес-логики приложения. Он создает новые сущности компонентов EJB, управляет их жизненным циклом и обеспечивает реализацию таких сервисов, как транзакция, безопасность, параллельный доступ, распределение, служба именования либо возможность асинхронного вызова.
Апплеты — это приложения из графического пользовательского интерфейса (GUI), выполняемые в браузере. Они задействуют насыщенный интерфейс Swing API для производства мощных пользовательских интерфейсов.
Приложениями называются программы, выполняемые на клиентской стороне. Как правило, они относятся к графическому пользовательскому интерфейсу (GUI) и применяются для пакетной обработки.
Веб-приложения (состоят из сервлетов и их фильтров, слушателей веб-событий, страниц JSP и JSF) — выполняются в веб-контейнере и отвечают на запросы HTTP от веб-клиентов. Сервлеты также поддерживают конечные точки веб-служб SOAP и RESTful.
Корпоративные приложения (созданные с помощью технологии Enterprise Java Beans, службы сообщений Java Message Service, интерфейса Java API для транзакций, асинхронных вызовов, службы времени) выполняются в контейнере EJB. Управляемые контейнером компоненты EJB служат для обработки транзакционной бизнес-логики. Доступ к ним может быть как локальным, так и удаленным по протоколу RMI (или HTTP для веб-служб SOAP и RESTful).
На диаграмме ниже представлена типичная архитектура Java EE приложения:
vchernogorov / _readme.md
Данный гист содержит основную информацию, которую нужно знать о Java Enterprise Edition.
JBs Component Architecture. Сервер- и клиент-слои могут включать в себя компоненты, основанные на архитектуре JBs компонентов, чтобы управлять потоком данных между: [source]
JEE Server Communications. Клиент связывается с бизнес-слоем, запускаемым на JEE сервере напрямую, либо через веб страницы или через сервлеты из веб-слоя. [source]
Web Container предоставляет базовые сервисы для управления и исполнения веб-компонентов (сервлетов, компонентов EJB Lite, страниц JSP, фильтров, слушателей, страниц JSF и веб-сервисов). Он отвечает за создание экземпляров, инициализацию и вызов сервлетов, а также поддержку протоколов HTTP и HTTPS. Этот контейнер используется для подачи веб-страниц к клиент-браузерам. [source]
EJB Container отвечает за управление и исполнение компонентов модели EJB (компонент-сеансы EJB и компоненты, управляемые сообщениями), содержащих уровень бизнес-логики вашего приложения на Java EE. Он создает новые сущности компонентов EJB, управляет их жизненным циклом и обеспечивает реализацию таких сервисов, как транзакция, безопасность, параллельный доступ, распределение, служба именования либо возможность асинхронного вызова. [source]
Application Client Container включает набор Java-классов, библиотек и других файлов, необходимых для реализации в приложениях Java SE таких возможностей, как внедрение, управление безопасностью и служба именования (в частности, Swing, пакетная обработка либо просто класс с методом main() ). Контейнер ACC обращается к EJB-контейнеру, используя протокол RMI-IIOP, а к веб-контейнеру — по протоколу HTTP (например, для веб-служб). [source]
Диаграмма связей между контейнерами. 
Введение в Java EE
Что такое Java EE
Java EE или Java Enterprise Edition представляет платформу для создания корпоративных приложений на языке Java. Прежде всего это сфера веб-приложений и веб-сервисов.
Java EE состоит из набора API и среды выполнения. Некоторые из API:
Enterprise JavaBeans (EJB) представляют классы, которые хранят бизнес-логику.
Contexts and Dependency Injection (CDI) предоставляет механизм для внедрения и управления зависимостями в другие объекты.
JSON Processing (JSON-P) позволяет работать со строками JSON в Java
JSON Binding (JSON-B) предоставляет функционал для сериализации и десериализации JSON в объекты Java.
WebSocket позволяет интегрировать WebSocket в приложения на Java.
JavaServer Faces (JSF) предоставляет возможности для создания пользовательского интерфейса на стороне сервера.
Эти и ряд других API сообственно и образуют то, что называется Java EE. Стоит отметить, что также в среде веб-разработки на Java популярна еще одна технология Spring. Фреймворк Spring не является частью Java EE и может использоваться как альтернативный подход к созданию веб-приложений на языке Java.
История развития
В начале 2019 года ожидается выход новой версии Jakarta/Java EE.
Официальный сайт платформы https://jakarta.ee/.
Установка IDE
Для работы с Java EE нам потребуется среда разработки или IDE. Есть различные среды разработки, которые ориентированы на корпоративную разрабоку под Java. Это IntelliJ IDEA, NetBeans и Eclipse. В данном случае на протяжении всего руководства мы преимущественно будем использовать Eclipse, потому что она является бесплатной и довольно широко распространена.
Для начала установим последнюю версию Eclipse, которую можно найти по адресу https://www.eclipse.org/downloads/. На странице загрузок выберем найдем рядом с названием текущей версии Eclipse кнопку «Download» и нажмем на нее.
После нажатия на кнопку нас перенаправит собственно на страницу загрузки, где необходимо будет нажать на кнопку «Download» для загрзуки установочного пакета:
После ее загрузки программы установки запустим ее и в отобразившемся списке опций выберем Eclipse IDE for Java EE Developers :
Далее надо будет указать папку для установки (или оставить выбранную папку по умолчанию) и принять пару лицензионных соглашений, и среда будет установлена.
Java Enterprise: что и как учить
Я выступал с аналогичной темой на IT fest, и, судя по реакции зала, людям было интересно. Формат доклада сжатый, многое пришлось проговаривать уже потом, отдельно от выступления. Да и качество записи вышло не очень, не всё слышно. Поэтому решил написать статью.
Сначала о себе любимом. У меня достаточно большой опыт работы java-разработчиком (с 2001 года, даже считать страшно), а программистом и того больше — с Большую часть из этих лет я работал тимлидом в разных аутсорсинговых компаниях Киева. Кроме того, более 10 лет я преподаю в учебных центрах Luxoft, NetCracker и вот IntroPro. И даже год вёл в школе информатику. В общем, обучать умею. Ну и с другой стороны, во многих компаниях я выступал как технический специалист, проводящий собеседование. Так что я еще и тот самый человек, который знает, о чем вас будут спрашивать на будущей работе. В этом году я принял участие в создании учебной программы по java в GoIT и преподавал в одной из групп. Большинство моих студентов уже работают.
Я это всё рассказал не ради хвастовства, а для того, чтобы пояснить, на чём я основываюсь, говоря о списке технологий и порядке обучения.
Итак, начнем, и внезапно с конца — я соберу выводы, которые сделал из обучения молодых специалистов.
Первый вывод самый печальный — программистами могут стать не все. И нечего смеяться! Изначально я рассчитывал, что научиться программировать может любой. А чего там, программирование — откровенно не rocket science. Бери больше, кидай дальше. Но всё оказалось не так. Всё уперлось в мотивацию. Сейчас объясню.
Не бывает людей вообще без способностей к программированию. Но всё равно — все люди разные. Так вот, обучаясь (в том числе и программированию), вы тратите мотивацию. Достигая чего-то в процессе обучения — вы мотивацию восполняете. И чем меньше у вас способностей, тем тяжелее вам продвигаться до очередного достижения. Если у вас было не так уж много мотивации, вы рискуете просто до следующего достижения не доучиться. А другой человек, возможно с меньшей мотивацией, чем у вас, но с большими способностями просто будет щелкать задачи как орехи и доучится. Се ля ви.
Второй вывод. Учиться java-разработчику без ментора, работающего в этой сфере — невозможно. Наша индустрия полна огромным количеством невнятных и даже контр-интуитивных знаний о том, как надо поступать и как не надо. Сами вы в этом не разберетесь. Гарантированно.
После конференции меня спрашивали — так что же делать, если наставника нет? Отвечаю: найдите себе ментора. Понимаете, программистам тоже надо расти, из миддлов становиться сеньорами, из сеньоров — тимлидами и так далее. И для всего этого надо получить опыт руководства, общения с подчиненными. И где его взять? Тут проблема та же самая, что и у джунов — нужен опыт, чтобы получить определенную работу. А получить его можно только на этой работе. Так что помогите друг другу.
Где найти такого ментора? Потусуйтесь на форумах программистов (на том же DOU) — постучитесь к людям в личку с вопросом: «Простите, а можно я буду вам время от времени вопросы задавать?» Большинство согласится. Полазьте на линкедин, в конце концов.
Третье. Самое важное, что делает java-разработчика java-разработчиком — привычка и способность быстро находить знания и впитывание их с необходимой скоростью. Именно на это должен быть нацелен процесс обучения джавистов. Учить их по классической университетской схеме (лекции, семинары) — бессмысленно. Только по жестокой схеме: раскачали и кинули в омут. Кто сможет — выплывет. Ну а если человек не может совладать с тем, что кроме него никто задачу не решит («есть ты и есть задача, все остальное зависит от тебя»), то ему программистом не стать. Другой разговор, что задачи должны быть подобраны с правильной сложностью — чтобы их можно было решить, но для этого требовалось напрячь все возможности.
Пока это только основные наброски (задачи уже есть и неплохо себя зарекомендовали, но критерии оценки результата пока чистая вкусовщина менторов), а хочется иметь точный план учебы со всеми реперными точками. Я над этим работаю, как будет готово, сразу сообщу. Предварительные наброски — в конце статьи, можете сразу переходить туда.
Что же должен знать java разработчик
Здесь я просто приведу список, а потом раскрою все пункты отдельно:
— Core Java;
— ООП;
— JDBC;
— Servers + Servlets +JSP;
— Spring;
— ORM;
— Web-frameworks;
— Web-services (SOAP, REST);
— SQL, HTML, JavaScript;
— Специфичные требования.
Core Java и ООП
Меня постоянно спрашивают, что я имею в виду под знанием ООП. Рассказываю. Прежде всего, это означает свободно ориентироваться в трёх принципах ООП. Понимать, как работает наследование и полиморфизм. То есть если один класс наследуется от другого, кого и к чему надо приводить, а что автоматически является экземпляром чего. Если у базового класса и у дочернего есть метод с одинаковой сигнатурой, то какие именно ограничения накладываются на типы принимаемых и возвращаемых значений, а также бросаемых исключений. Что будет в compilation time, а что в run time. Ну и так далее. Человек, который этого не понимает, нормальный код не напишет — это уже проверено. Лично мы таких просто не берем, даже если у человека хорошие знания фреймворков. Себе дороже будет потом его код поддерживать.
Из Core java нужно знать методы объекта Object и Collection Framework. Enterprise java — это на 90% ковыряние в разных коллекциях. От них никуда не уйдешь.
Так же часто спрашивают про concurrency. Отвечу несколько спорно, но по моему опыту так. Есть проекты, которые жестоко завязаны на многопоточность. Для найма в эти проекты вас буду жестоко гонять по concurrency. В других проектах многопоточности особо нет, и вас там про нее ничего не спросят. Думаю, общее представление иметь необходимо всем, учить ли глубже — сами решайте. Другой разговор, что есть множество собеседователей, которые страшно любят эту тему и будут вас по ней спрашивать, даже если для проекта это все нафиг не надо. Почему именно многопоточность пользуется у них такой большой любовью — тут я только руками развожу.
JDBC (Java Database Connectivity)
Зачем учить то, чем никто уже в чистом виде не пользуется? По двум причинам.
Во-первых, новичков любят нанимать на проекты поддержки (support). А это в большинстве своем весьма древний софт, написанный кем-то левой задней. И вероятность того, что там используется plain JDBC — не нулевая.
Во-вторых, под капотом у всех ORM-ов все равно лежит тот же самый старый добрый JDBC. И рано или поздно (скорее рано, чем поздно), когда у вас что-то сломается, вы увидите как раз ошибки JDBC. И с этим надо будет что-то делать
Servers
Тут все просто. Любой java разработчик должен знать Tomcat. Он самый простой, самый легкий и пожалуй, имеющий наибольшую knowledge base. Спрашивать на собеседовании о нем вас никто не будет — предполагается, что вы его и так знаете. Не знать томкет — это стыд и позор. Имейте в виду.
Дальше стоит изучать уже JBoss/WildFly — всё-таки многие J2EE технологии на томкете не работают (те же EJB или кластерное решение, хотя, может, я отстал от жизни). А вот JBoss/WildFly — как раз оптимален. Он бесплатен и вполне функционален. Никто не ожидает от новичка, что он взял и скачал где-то WebLogic и фигачит код под него. А вот знание JBoss/WildFly — самое оно. Более того, он частенько используется даже у серьезных заказчиков
Unix-like
Про знания юникса вас могут максимум спросить — владеете ли и на каком уровне. Сразу отвечаю — достаточно владеть на уровне пользователя. Запустить, остановить, воспользоваться SSH и SCP. Ну в общем-то и все.
Servlets + JSP
Этот пункт аналогичен пункту про JDBC. И встречаются они всё-таки иногда, и знание того, что под капотом более современных web фреймворков — очень полезно. Как минимум, сокращает время нахождения ошибки в разы. Лишним не будет. Да и спросить на собеседовании об этом вполне могут.
Spring
Знание спринга — ультимативно. Как минимум, потому что спринг — отраслевой стандарт. И не важно, нравится вам спринг или нет. Главное, чтобы вы его знали. С вероятностью 80% вы будете с ним работать уже на одном первых трёх проектов. Да и вообще, энтерпрайз разработчик не должен перебирать — это хочу, это не хочу. Взялись и работаем. Вот это как раз тот случай.
Есть ещё CDI, стандарт от Оракла. Я провел опрос среди своих друзей, спрашивая, кто им пользуется. 80% ответили: «А что это такое?. Остальные 20% сказали: «Нет, не пользуемся». Так что можете смело на него забить.
Промышленным стандартом является Hibernate. Опять же, нравится он вам или нет, знать вы его обязаны. Использовать должны через JPA.
Объем знаний: уметь замепить отношения один-к-одному, один-ко-многим и многие-ко-многим. Написать HQL запрос и настроить лейзи загрузку.
Web-framework
В этом пункте всё-таки вкусовщина, но знание какого-либо веб-фреймоврка необходимо. JSF, так JSF. SpringMVC, так SpringMVC. Всё будет хорошо. Главное, чтобы вы могли хоть каким-то образом отрисовать UI. Все веб-фреймворки сходны в принципах работы, так что учите то, что покажется наиболее востребованным.
Web-services (SOAP, REST)
С SOAP сложнее — надо знать несколько ключевых слов, описать, для чего служит WSDL, ну и представлять общие основы протокола.
SQL, HTML, JavaScript
Знание SQL — ультимативно. Вы должны его знать на уровне джавы. Сейчас даже на проекты, использующие NoSQL базы, не берут без хорошего знания SQL. Что уж говорить об остальных. Почему он так нужен — объяснять не буду, но если вкратце — на SQL вы будете писать часто и много. Естественно, не хранимые процедуры (хотя это тоже не исключено, но это всё-таки экзотика), но запросы на вставку и проверку тестовых данных — очень часто.
Я не беру людей на должность в двух случаях. Если они заваливаются на первом пункте (Core Java и ООП) и на этом. Делайте выводы.
Насчет знания HTML я даже говорить не буду. Чего там знать? Прочитал статью — ты уже его знаешь.Естественно, все хитрости и заморочки современных CSS — это хлеб Front End. Вот пусть они там и пасутся. Мы же должны хорошо знать HTML и немного JavaScript. Причем, знание JavaScript — отличный бонус для новичка. Знаете почему? Потому что новичков любят брать на саппортовый проект, в котором давно уже не работают дизайнеры. Java-скриптик подправить иногда надо, а джаверы его не любят. И если вы, в отличии от остальной команды, готовы им заниматься — все будут вас любить. И вы с бОльшими шансами попадете на работу, чем чистоплюи, которые не хотят ковыряться в этом вашем фронт-энде. Так что любите JavaScript, и будет вам счастье.
По объёмам знаний. Надо знать сам JavaScript. Хорошо также уметь читать JQuery. А ещё лучше — уметь его писать. Если вы обладаете соответствующим опытом — не стесняйтесь указать их в резюме. Это смежные с нами знания. Это вам не PHP какой-нибудь, про который джаверы говорят: «У тебя до сих пор есть в резюме PHP, тебе не стыдно?»
Знания скриптовых языков (sh, bash, perl &etc) — штука полезная. Как минимум, вы увеличиваете свои возможности по затыканию дыр — а это и есть основная суть работы на саппортовом проекте. Другой разговор, спрашивать вас об этом на собеседовании не будут, а выучить основы такого языка — дело пары дней. Так что я бы не советовал в это упираться.
Специфичные требования
Вы должны быть готовы, что при приеме на работу вас первым делом спросят: «А знаете ли вы фреймворк бла-бла-бла 4.2?» Нормальный ответ — нет, не знаю. В любом проекте есть какие-то странные вещи, которые только там и используются. Все знать вы не можете и не должны даже пытаться.
Как выбрать специализацию
Очень советую всем начинающим программистам выбрать себе специализацию. Сейчас объясню, что я имею в виду. Мы все — java-разработчики. Ок, все знают джаву, все знают более менее полный стек наших фреймворков. Но, в любом проекте будет цениться человек, который реально хорошо знает один из нужных фреймворков. Например — гуру по Hibernate. Или гуру по какому-нибудь PrimeFaces. Или — мощный знаток Oracle DB.
Вы поняли, к чему я. Да, знать нужно все, но что-то одно — выучить досконально. И поразить своими глубокими знаниями об устройстве вашего любимого фреймворка собеседователя. Да, естественно не в каждой команде нужен специалист именно по вашему любимому фреймворку. Там вы просто будете обычным джавером. Но в какой-то команде ваше появление будет встречено аплодисментами — «О! именно ты и был нам нужен, тебя нам послало небо!» Короче, вы поняли. Будьте как все, но немножко лучше 🙂
В каком порядке всё это изучать
Значит так, сначала ставим цели. Мы должны добиться того, чтобы новичок не боялся чудовищного массива знаний и привык к тому, что всё он не будет знать никогда. И научился работать в ситуации неполного знания.
Пока методика выглядит следующей:
1. Погрузиться в сложные алгоритмические задачи. Главное, чтобы эти задачи еще не были реализованными в готовых библиотеках, и человек понимал, что задача относительно реальная. Например — вывести что-то отформатированное. Смысл: вызывать у человека понимание, что любая задача решаема. Просто нужно несколько дней подумать, покрутить задачу, и вот тогда все выйдет.
2. Нарисовать к этим задачам Unit tests. Юнит тесты легко покажут все ошибки вашего проектирования и заставят переписать код в гораздо более приличном формате. Как бонус — студент привыкает не бояться править код снова и снова. Это умение абсолютно необходимо для профессионального программиста
3. Научиться декомпозиции. Выбрать несколько предметных областей и порисовать по ним UML диаграммы. Это необходимо, чтобы просто понять — это и будет самым сложным в нашей работе. Единственное замечание — диаграммы должны проверяться опытным и толковым ментором. На этом этапе ментор просто необходим. Настроить свой мозг на вырезание скоупа проекта, на декомпозицию объектов и их взаимосвязей — это то, что само не придет, сколько не программируй.
4. Сделать код на основе результатов одной из декомпозиций. Этот код будет впоследствии нашим слоем бизнес-логики.
5. Начинать работу с базой. Освоить JDBC и все его части. Это будет существенно проще после предыдущего пункта. Код также необходимо показать ментору. Как показывает моя практика, многопоточность (которая в любом случае предполагается для этого кода) — штука не сразу лезущая в голову. Надо, чтобы вас направили.
6. Выучить основы веба и томкет. Надо сделать к вашей бизнес-логике и DAO layer последнюю оставшуюся часть — UI. Пока на сервлетах и JSP. Нужно сделать так, чтобы JSP обращались к бизнес-логике за ее данными. Та запрашивала данные из базы и возвращала их на View (JSP). По нажатию на кнопки в JSP управление передавалось в сервлеты, которые отправляли команды бизнес-логике на изменение состояния. А та, в свою очередь, меняла данные в базе с помощью DAO layer. И затем сервлеты отправляли управление обратно на JSP (например — редиректом), и затем все повторялось. Тут надо внимательно следить, чтобы никакие запросы от JSP не лезли в DAO layer.
7. Изучить возможности томкета. Создаем Data Source и работаем уже не с физическим коннектом, а с логическим, получая его через JNDI.
8. Освоить Spring. Все, что нужно сделать — проинжектить DataSource в нужные классы DAO Layer. Сначала — через XML конфигурацию, а потом — через аннотации. Этих знаний будет достаточно
9. Теперь можно вводить Hibernate через JPA аннотации. Смысла изучать меппинг-файлы я не вижу. Они уже почти нигде не используются. Заменяем весь код в DAO на HQL или Criteria. Что лучше пойдет.
10. Ну и наконец, самое веселое — выбираем фреймворк для морды. Я бы порекомендовал какой-то JSF или SpringMVC.
Дальше, когда ключевые вещи освоили, изучать можно уже что угодно. Я бы рекомендовал погрузиться в SQL, WebServices и JavaScript
Обращаю внимание: перескакивать этапы крайне не советую.
Если у вас получится следовать этому плану, и ваш ментор окажется достаточно квалифицирован, всё будет отлично. И скоро на одного Java разработчика станет больше. Удачи вам!
Маєте важливу новину про українське ІТ? Розкажіть спільноті. Це анонімно. І підписуйтеся на Telegram-канал редакції DOU