Андрей К

Есть два подхода Code first и Database first, разные инструменты могут реализовывать один или оба. В первом структура БД определяется кодом, а во втором наоборот.

Имя поля/столбца можно подменить, но если в место sum будет что-то другое, что это для Вас поменяет?

А вообще, все зависит от задачи. Могут в БД хранится данные, а потом на уровне сервисов производится преобразования, которые дают данным новое качество. Поэтому учитесь думать не кодом, а задачей, которую Вы решаете.

Первое, магические числа - это страшный косяк.

Второе, если нужно использовать выбор для ограниченного количества значений, то нужно использовать Enum.

Java RMI или сериализация в json/XML.

Подумайте сами, как может конструктор отработать на половину? Он же вернет ссылку на результат своей работы вызываемому коду когда исполнится весь. Конечно с дуру можно и член сломать, но зачем Вам в конструкторе передавать указатель на себя еще куда-то?
По Вашему примеру рождается вопрос, не идет ли речь про Singleton? Если да, то 2 из 4 способов реализации этого паттерна описанные в книге Джошуа Блоха потокобезопасные.

P.S. Суть volatile в том, что Вы говорите не кешировать это значение в процессоре, а всегда спускаться в память (кстати, тут я не знаю, если в системе один процессор Intel, у них в отличии от AMD кеш третьего уровня общий, будет ли использован он или все равно только память), чтобы работать со свежим значением. Без этого два ядра могут долго работать со своими значениями, но вот атомарность записи этого значения не гарантируется. То есть, например int будет атомарно меняться, а вот long уже нет. Поэтому, на счет ссылок не уверен, они вроде бы тоже 64 бита, по идее, они тоже должны быть не атомарны, но может там другая защита, а то создадим два объекта и получим ссылку непонятно куда.

По-моему логично, что если Вы хотите получить объект произвольной структуры, там Вам нужно реализовать руками конечное преобразование.

Заметна "динамическотипизированная" :-D

Согласен, тяжело переключаться, но в Java так нельзя.

В зависимости от реализации библиотеки нужно сравнить с null или каким-то пустым объектом,так как элемент теоретически может быть пустым, но существующим.
Условно говоря if (userCity.text == "") {...} или как-то так, конкретно не знаю реализацию этой библиотеки.

P.S. В C# есть прикольный статический метод у строк, что можно проверить это пустая строка или null одной функцией.

Адаптер - это паттерн, который позволяет преобразовать один интерфейс к другому.
ClassLoader - это специальный Java класс, который загружает другие Java классы в память.
Чтобы создавать объекты разных типов в зависимости от условий - используются Фабричный метод или Абстрактная фабрика.

В общем, научитесь называть вещи своими именами и сразу все становится на правильные места.

Да любой... Но если смотреть по вакансиям, то, все-таки, Angular.

Начнем с того, что сама постановка вопроса в корне не правильная. Это могло бы звучать так: "я сделал код, провел замеры и все уперлось в операцию cast, что мне делать?".

Это же прописанные истины, преждевременная оптимизация - корень зла!

Но если на сам вопрос, то операция приведения типа должна быть быстрая, но как уже написали, тут явно не тот случай, когда ее нужно применять.

Меня смущает ClassPathXmlApplicationContext, если конфигурация через аннотации.
По идее, AnnotationConfigApplicationContext должен помочь.

Первое, что можно сделать, попробовать напроситься хоть на бесплатную стажировку.
Если получиться, то можно исходить из того, куда получиться попасть.
Если это будет JavaEE, то никто дома не мешает шалить с Android :-)