Я полтора года назад устраивался на должность Junior Java EE разработчиком в Москве.
У меня не то что опыта Java EE разработки не было, у меня не было даже трудовой книжки.
В резюме так и написал: мол опыта Java EE нет, но про Java слышал, про спринги всякие читал,
ну и приложил ссылочку на свой репозиторий на гитхабе с опенсорс-библиотечкой на Java (ничего особенного, простая обертка над API сайта, день-два работы).

По моим ощущениям, если у тебя нет опыта в Java EE, то у тебя нет опыта в Java EE и им пофиг че ты делал до этого.
У меня на собеседовании даже не спрашивали что я писал (кроме вышеуказанной библиотеки), какие проекты делал (до этого я немного фрилансил на php)
и с чего я решил что знаю Java. Дали бумажный тест по Java и SQL. Потом побеседовали по основам java: коллекции, потоки, синхронизация и т.д.
по базам: типы связей (один-к-одному/один-ко-многим/многие-ко-многим), транзакции, ACID и в таком духе, ну и в общем плане: процессы, потоки, http-протокол.
Видимо я не слишком сильно плавал в вопросах, а может их просто устроили мои скромные запросы по ЗП (скромничать, кстати, не советую, выйдет боком, но это уже другая история).
Меня взяли.

Вместо постскриптума.
За неделю работы там я узнал больше чем за пару месяцев самостоятельного изучения спринга и Java EE в целом.
Java EE на самом деле очень обширная область, а Java SE это так, верхушка айсберга.
Мозги реально кипели от объема поступаемых новых данных, попутно приходилось дома читать книжки и добирать основы где не хватало.
Еще смешное, в Java EE на 5 строк java кода приходилось строк 20 xml конфигурации :D Видимо поэтому не особо гоняют по самой Java. Больше времени тратишь на настройку и свзку всяких фреймворков и серверов.

В общем, налегайте на основы, читайте и самое главное пишите.
Когда начинаешь писать сразу всплывает куча нюансов и непонятных java экспешенов (куда же без них).
И еще, если с английским проблемы, налегайте на английский. Вся документация на английском.
На русском либо её нет вообще, либо её крайне мало, либо она уже устарела.

Отвечая на Ваш вопрос(имхо, по моим ощущения и по опыту чтения форумов): опыт Android-разработчика _преимуществ перед_ Java EE-работодателем вам особых не даст.
Android платформа с Java EE имеет мало общего, но хуже от него само собой не будет.

Извините за многобукаф, Остапа понесло.

dev.mysql.com/doc/refman/5.1/en/alter-table.html
Если посмотреть документацию то можно заметить, что для CHANGE также указывается новое имя колонки, в то время как в MODIFY меняется только ее описание.
| CHANGE [COLUMN] old_col_name new_col_name column_definition
[FIRST|AFTER col_name]
| MODIFY [COLUMN] col_name column_definition
[FIRST | AFTER col_name]

UPD:
> Это нормально что в контроллере столько много catch'eй?
Не то чтобы нет, но "попахивает".
> как быть, если у меня возникает несколько исключений, и я хочу выдать пользователю информацию о всех возникших сразу

У вас смешана валидация входных параметров с возникновением нештатных ситуаций.
Exception стоит кидать если метод не может вернуть осмысленный результат.
Ошибки валидации ("сообщение слишком длинное", "файл не того расширения") можно собирать, к примеру, в массив. Как валидировать входные данные выходит за рамки этого вопроса.
------
> Можно ли так делать?
Попробуйте использовать правило 5 почему (ну или "зачем") чтобы попытаться добраться до сути.

- Я даю отдельные имена исключениям.
- Зачем?
- Для того что бы отловить различные ошибки.
- Зачем отлавливать различные типы ошибок?
- Чтобы показывать разные сообщения.
- Зачем показывать разные сообщения?
- Чтобы пользователь мог отреагировать определенным образом на конкретный тип ошибки
(решить что ему делать в случае конкретного исключения).

Давайте посмотрим что человек (пользователь) на вашем сайте (системе) может сделать в случае ошибки:
1. Не корректное сообщение.
Привести его к корректному (сделать его короче, как-то отформатировать и т.п.)

2. Не удалось загрузить файл.
Если файл слишком большой - можно попробовать загрузить файл поменьше.
Если это внутренняя ошибка (например: закончилось место на диске на сервере, нет прав на запись и т.п) - то ничего, здесь уже требуется вмешательство тех кто обслуживает систему.

3. Ошибка PDO.
Ничего, это внутренняя ошибка.

Т.е. есть смысл создавать новый тип исключения, если пользователь системы может иначе отреагировать на этот тип.

Я использую 2 типа исключений на уровне web-слоя: внешние и внутренние.
Внешние - если пользователь может повлиять на них (страница не найдена, файл слишком большой, нет доступа и т.п.).
В них сообщение показывается пользователю как есть. Подноготная (пути к файлам, пароли, названия БД и т.п) в такие ошибки не вкладывается.

Внутренние - пользователь не может влиять (ошибка подключения к БД, SQL syntax error и т.п).
Пользователю показывается только код ошибки. В такие ошибки также вкладываю техническую информацию.

Ты (как программист) также можешь быть пользователем какой-то системы (к примеру, библиотеки).
Например, библиотеки для работы с БД.
Предположим ты импортируешь csv-файл в базу, заполняешь числовую колонку и вместо числа у тебя попадается текст.
Запрос падает с ошибкой и тебе не плохо бы отличать её от ошибки синтаксиса.
Если попался текст вместо числа - то можно просто пропустить строку.
Если ошибка синтаксиса - то у ошибка в коде и продолжать импорт нет смысла.

Подытожу:

> Можно ли создавать свои пустые классы Exception'ов наследуемые от класса Exception только лишь для того что бы было отдельное имя исключения?

Можно.

Сколько делать отдельных исключений?
Зависит от того как их будет обрабатывать пользователь.
Если твой контроллер(модель, подсистема) кидает множество разных ошибок и все они обрабатываются одинаково - то стоит призадуматься.

Пальцем в небо
sql_query_pre = SET NAMES utf8