click_f

Правой клавишей по проекту, выбрать пункт Add framework support, выбрать Maven. Будет создан pom.xml. Открываете его в редакторе, нажимаете Alt+Insert, выбираете пункт Dependency, добавляете из списка нужные.

ну или для вашего случая

for k in test['set']['item']:
    print(k['i']['n'])

@ConfigurationProperties, например
а потом sp-el и понеслась

@Value("${name}")
private String name;

Если одним префиксным/инфиксным/постфиксным — то, разумеется, нет. А если двумя — дело уже интереснее (при условии, разумеется, что все узлы разные).
Ну, например, как восстановить дерево, которое было пройдено сначала префиксно, потом постфиксно (самый сложный и интересный случай). Признаюсь сразу: полное восстановление невозможно, ведь ситуации «без левых сыновей» и «без правых сыновей» различить нельзя.

Если длины не совпадают, СТОП: некорректные данные.
В префиксном обходе корень в начале, в постфиксном — в конце. Если они не одинаковы, СТОП: некорректные данные.
Если в обходе один элемент — с этим всё понятно.
Второй элемент префиксного обхода — левый сын. Ищем его в постфиксном обходе. Если он предпоследний — перед нами та самая ситуация «у дерева один сын», и рекурсивно запускаем алгоритм на обходах без корня.
В противном случае выкусываем подстроки нужной длины (реально или виртуально), дважды запускаем алгоритм рекурсивно.

Пример: у нас дерево.

     a
  b    c
d  e   f

Префиксный обход abdecf, постфиксный debfca. Корень a, левый сын b, он в постфиксном обходе на третьей позиции. Рекурсивно запускаем алгоритм на парах bde/deb и cf/fc.

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

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

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

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

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

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

Лучше всего использовать именно PreparedStatement, если не используете какой нибудь ORM.
1) Это безопасно, так как исключает позможность SQL-injection
2) Это типо-безопасно - java-way.
3) Это быстро, в некоторых типах jdbc-драйверов они компилируются в хранимые процедуры на стороне базы (например в sybase/mssql и oracle) или в псевдокод на стороне java, а также они кешируются.

Пользуйте везде, где можно именно PreparedStatement - javarevisited.blogspot.ru/2012/08/top-10-jdbc-best...
и javarevisited.blogspot.ru/2012/03/why-use-prepared...

value - для примитивов, стрингов, ${пропертей} и #{Spring Expression Language}.
ref - если нужно заинжектить бин. В ref указывается id бина

Работая с JDBC, вы непосредственно работаете с базой данных, ORM же представляет "обертку" для того же JDBC, которая (ORM) реализует паттерны, обеспечивающее большее удобство, помогает ускорить разработку, очевидно что лучше предпочитать второе, но первое проще для простых задач, более гибко, а также помогает освоить второе.

Для начала упростим JDBC до общего случая Data Access Object (DAO).

Суть DAO сводится к тому, что у нас есть объект, инкапсулирующий в себе работу с хранилищем данных. Ну то есть весь SQL и все детали работы с хранилищем вшиты в него. Причем их может быть множество (не пихать же вообще всю работу с базой данных в один объект).

Словом, основная задача DAO - предоставить механизм работы с базой данных скрывая детали внутри себя.

ORM (Object-relational mapping) - это, если опять же упростить, общая идея конвертации "объектов" между системами с несовместимыми типами. Ну то есть как объекты из базы мэпятся на объекты.

Если под ORM брать мощные реализации вроде Hibernate, то тут становятся очевиднее минусы конкретно этой реализации. А именно - работать это будет эффективно когда вам нужно построить объектную модель логики приложения, нежели модель данных. Такие подходы хорошо работают в приложениях с реально сложной логикой, где вам бы хотелось в коде передать суть того, как все работает в реальности. Например как именно происходит автоматизация бизнес процесса. С реальными объектами и т.д.

Для вещей вроде генерации репортов ORM такого плана приносят больше вреда чем пользы. ORM очень хорошо работают в операциях на запись, ито только если речь идет о взаимодействии небольшого количества объектов (пара сотен например, или десятков но не тысяч), когда логика взаимодействий этих объектов сложная, или правил много. Если вам скажем нужно обновить все значения в таблице - сделать это через SQL намного удобнее.

Ну и в целом, ORM и DAO это весьма разные концепции, они о разных вещах. То есть у вас может быть использовано и ORM и DAO. Или ORM внутри использующее DAO... это не столь важно.

JDBC- интерфейс для sql-запросов. Работаете с голыми sql-запросами и оперируете таблицами, строками, колонками и значениями. Если результаты запроса нужно положить с объекты, то сами их туда распихиваете.
ORM - интерфейс для мапинга классов на таблицы, строки, колонки и значения базы данных. Работаете с java-объектами, sql-запросы за вас формирует ORM. Другими словами, не задумываетесь (почти), каксоставить sql-запрос, вытащить из него данные и раскидать значения по своим классам.
Предпочтительнее конечно работать с ORM, так как все за вас будет оптимизировано и закешировано. Конечно, нужно будет знать, не только как работает ваша база данных, но и как работает ваш ORM.