История изменений

Можно ли где-то почитать про подобные ловушки?

ответ на этот вопрос состоит из двух частей.

если тебе серьезно нужно изучить тонкости джавы, то советую смотреть всё, что публикует https://www.youtube.com/user/JUGRuVideo

эти видики хороши тем, что они не скучные. То есть их можно посмотреть реально много, прежде чем возненавидишь, в отличие от говнотекстов с сайта Роза Индии :)

ну и почитать какую-нибудь классику, типа Джошуа Блоха Effective Java, Java Concurrency in Practice, итп (тут нужно думать над списком классической литературы)

по тонкостям дизайна базовой джавы придется прочитать стандарт: Java Language Specification и Java Virtual Machine Specification

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

таким образом можно узнать что-нибудь теоретически полезное, например как устроен HashMap, и своим мозгом понять какая по нему скорость поиска

по тонкостям прикладного - берешь документацию по Spring, Hibernate, или что ты там собираешься использовать, так чтобы у тебя был полный список фич фреймворка. И последовательно их используешь.

(для Hibernate это как минимум древняя дока Hibernate Annotations, с тех пор там ничего не менялось. Для Spring это целиком полностью HTML с их официального сайта - она простая, но очень нудная и длинная, в первый раз я ее осилил только за неделю).

На основании этого складывается понимание дизайна фреймворка. И вот только после этого можно начинать писать на нём совершенно новый проект.

Это звучит дико, но большинство архитекторов проектов с использованием Spring или Hibernate, или чего угодно еще, никогда этого не делали. Поэтому все их проекты такие архитектурно убогие и корявые, и состоящие из одних костылей.

===

если тебе нужно пройти собеседование. И общаться на собеседовании с придурками, одержимыми своим ЧСВ, которые спрашивают идиотские вопросы про сравнение интов через ==, то нужно:

- подготовиться по материалам для Oracle Java Certified * (Associate, Programmer, Architect, ...) какие найдешь на торрентах. Там просто отборная порция идиотии, придумать самостоятельно это нереально :)

- посмотреть что написано в вакансии (например, «Hibernate»), и
--- загуглить по запросу типа «Java Hibernate interview questions»
--- загуглить по кейворду «Hibernate Cheatsheet», особенно в гуглокартинках как ни странно, и зазубрить всё что увидишь на этих шпаргалках. Обычно там написано то, на что не решаются пойти авторы профильных книг - иначе бы это показало бессмысленность чтения этих книг
--- прочитать соотстветствующую документацию (древняя дока Hibernate Annotations, простыня HTML с сайта Srping, вот это всё). Запомнить в голове хотя бы оглавление, чтобы понимать список фич фреймворка. По возможности еще и закэшировать в голове синтаксис, идиоты любят спрашивать задачи типа «сообщите точный список параметров у @RequestMapping».

В результате этой офигительной подготовки знать ты ничего не будешь, но среднему собеседовальщику (который как правило тоже ничего не знает) не хватит скилла этого понять :)

Можно ли где-то почитать про подобные ловушки?

ответ на этот вопрос состоит из двух частей.

если тебе серьезно нужно изучить тонкости джавы, то советую смотреть всё, что публикует https://www.youtube.com/user/JUGRuVideo

эти видики хороши тем, что они не скучные. То есть их можно посмотреть реально много, прежде чем возненавидишь, в отличие от говнотекстов с сайта Роза Индии :)

ну и почитать какую-нибудь классику, типа Джошуа Блоха Effective Java, Java Concurrency in Practice, итп (тут нужно думать над списком классической литературы)

по тонкостям дизайна базовой джавы придется прочитать стандарт: Java Language Specification и Java Virtual Machine Specification

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

таким образом можно узнать что-нибудь теоретически полезное, например как устроен HashMap, и своим мозгом понять какая по нему скорость поиска

по тонкостям прикладного - берешь документацию по Spring, Hibernate, или что ты там собираешься использовать, так чтобы у тебя был полный список фич фреймворка. И последовательно их используешь.

(для Hibernate это как минимум древняя дока Hibernate Annotations, с тех пор там ничего не менялось. Для Spring это целиком полностью HTML с их официального сайта - она простая, но очень нудная и длинная, в первый раз я ее осилил только за неделю).

На основании этого складывается понимание дизайна фреймворка. И вот только после этого можно начинать писать на нём совершенно новый проект.

Это звучит дико, но большинство архитекторов проектов с использованием Spring или Hibernate, или чего угодно еще, никогда этого не делали. Поэтому все их проекты такие архитектурно убогие и корявые, и состоящие из одних костылей.

===

если тебе нужно пройти собеседование. И общаться на собеседовании с придурками, одержимыми своим ЧСВ, которые спрашивают идиотские вопросы про сравнение интов через ==, то нужно:

- подготовиться по материалам для Oracle Java Certified * (Associate, Programmer, Architect, ...) какие найдешь на торрентах. Там просто отборная порция идиотии, придумать самостоятельно это нереально :)

- посмотреть что написано в вакансии (например, «Hibernate»), и
--- загуглить по запросу типа «Java Hibernate interview questions»
--- загуглить по кейворду «Hibernate Cheatsheet», особенно в гуглокартинках как ни странно, и зазубрить всё что увидишь на этих шпаргалках. Обычно там написано то, на что не решаются
--- прочитать соотстветствующую документацию (древняя дока Hibernate Annotations, простыня HTML с сайта Srping, вот это всё). Запомнить в голове хотя бы оглавление, чтобы понимать список фич фреймворка. По возможности еще и закэшировать в голове синтаксис, идиоты любят спрашивать задачи типа «сообщите точный список параметров у @RequestMapping».

В результате этой офигительной подготовки знать ты ничего не будешь, но среднему собеседовальщику (который как правило тоже ничего не знает) не хватит скилла этого понять :)