Владимир Голованов

jsfiddle
Вы сами проверили на ИЕ10 на jsFiddle? Повторяется ли ошибка? Не вижу проблемы

Любую и постепенно разбираться в мелочах, которые вам непонятны. До самой смерти.

Как речь заходит про Java-литературу - непременно обсуждение вокруг Эккеля-Шилдта-Хортсмана-Сьерра крутится. Есть из вариантов а-ля "полное руководство" ещё весьма недурственный Хабибуллин, кстати. Но я не об этом.

Если уже в наличии некоторый опыт, то предлагаю для вхождения в Java альтернативный вариант.

Седжвик Р. "Алгоритмы на Java". Книга о фундаментальных алгоритмах (сортировка-поиск-графы-строки). Погружение в Java происходит между делом, поскольку этот ЯП выбран в качестве иллюстрации примеров. О самом языке даются базовые сведения, но происходит это легко и непринуждённо, Java проходит ненавязчивым фоном в процессе изучения интереснейших тем. Автор - гуру computer science и блистательный университетский преподаватель.

Макконелл С. "Совершенный код". Мастер-класс о правильном стиле программирования. Львиная доля примеров - на Java (ну и к С++ ещё автор слабость питает).

После этих книг проще штудировать фундаментальные трактаты по Java. Язык теперь будет восприниматься как нечто естественное, а не чужеродное для Вашего разума.

1. Аннотация @Inject относится к CDI и управляется им (референсная реализация — Weld).
2. Любой dependency injection фреймворк требует управления бинами через него, соответственно создавать объекты через new в общем случае нельзя. Если вам требуется экземпляр Controller-а — создавайте его так же, через @Inject.

Классная идея! Я бы поучаствовал.

Если уж речь зашла о модуляризации в Java, то уместно вспомнить об OSGi, поддерживаемой Spring.

Вот тут описывается поддержка веб-приложений. OSGi позволяет собирать ресурсы (классы, JSP, tld) из разных модулей или фрагментов. Описание, правда, выглядит несколько сложным. В реальности всё как-то проще.

Заполненность поля сертификат говорит лишь о сертификате, о типе авторизации оно говорить не может. Может лишь косвенно намекать и этот намёк по стечению обстоятельств может быть правдивым — но полагаться на это 100% нельзя, особенно учитывая возможную эволюцию кода.

С точки зрения эволюции кода, безопаснее использовать, например, перечисления (enum). Не «правильнее», а именно «безопаснее», в смысле будущих модификаций.

Вдруг (наверняка?) у вас возникнет необходимость в дополнительных способах аутентификации (OAuth например)? В случае использования перечислений (или других аналогов шаблона «визитёр» — типа case classes из Scala), среда разработки подскажет вам, где вы забыли учесть новый вариант аутентификации. Не знаю как Visual Studio, а Eclipse или IDEA выдадут предупреждение в следующем коде:

switch (principal.getAuthMethod()) {
case LOGIN: /* Login / password auth */
    break;
case CERTIFICATE: /* Certificate auth */
    break;
}

как только добавится новый тип аутентификации (OAUTH). Это даст вам знать, что вы забыли учесть новый способ ещё в каком-то месте.

Так что если IDE помогает в таком деле, то почему бы этим не воспользоваться?

Вы говорите что методы hashcode и equals перегружены — значит надо перегрузить их сильнее и сравнивать даты с точностью до секунд

Есть несколько разновидностей тестов. Если вы бэкэнд-разработчик, то вас, в первую очередь, будут интересовать два вида:

1. Юнит-тесты
2. Интеграционные тесты

Юнит-тесты — тесты, направленные на тестирование отдельных частей класса. Чаще всего это методы. Иногда — отдельные ветки методов (всегда справедливо для god objects).
Самый важный пункт: для юнит-тестирования не нужно поднимать контекст приложения! Вы тестируете логику отдельного юнита, а не связку классов. Поэтому, очень часто для юнит-тестирования использую мок-фреймворки (как пример — мокито). Это нужно для того, что не писать руками -заглушки связанных классов.

Что покрывается юнит-тестами? В первую очередь покрывайте бизнес-логику (сервисы, классы-менеджеры). После — контроллеры. Можно покрыть DAO-слой (опять же, если там есть сложная логика)0.

Как пишется юнит-тест? Вы берёте набор входных параметров, мокаете классы-зависимости, передаёте входные параметры в тестируемый метод и проверяете выходные параметры. Если в методе есть условия — необходимо попасть во все ветки.

Писать ли отдельный тестовый метод для каждой ветки? Это зависит от вашего стиля и от того, планируете ли вы рефакторинг в ближайшем будущем. По-хорошему, стоит выделять отдельные крупные ветки в отдельные методы, особенно для god objects.

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

Нужны более глубокие подробности — пишите :)

Философия java (Брюс Эккель) www.ozon.ru/context/detail/id/4073388/
Совершенный код (С. Макконнелл) www.ozon.ru/context/detail/id/3159814/
Паттерны проектирования (Банда четырех) www.ozon.ru/context/detail/id/2457392/
Рефакторинг (Мартин Фаулер) www.ozon.ru/context/detail/id/1308678/
Алгоритмы. Построение и анализ (Кормен) www.ozon.ru/context/detail/id/2429691/

Я считаю, что эти книги как минимум один раз необходимо прочитать, а потом по мере необходимости заглядывать:)

Неизбежные накладные расходы.

Например, программа, которую вы написали, делает полезную работу в течение 10 мс, но на запуск и завершение виртуальный машины Ява уйдет дополнительно 5 секунд, и эти 5 секунд будут оверхедом.

Это понятия из разных сфер.

1) Есть модель клиент — сервер. Смысл что клиент может делать запосы серверу, а сервер на них отвечать.
Приложение, которое использует какой то сервис в интернете является клиентом этого сервиса. И в каком то контексте является клиентским приложением.

2) Есть модель браузерных приложений. С этой точки зрения «десктопное» приложение — это приложение, которое разворачивается как бы на рабочий стол. То есть является полноценным приложением операционной системы.
Наобором браузерное приложение — приложение, которое запускается в рамках браузера, а операционная система о нем не знает.

3) Есть модель мобильных приложений. Это приложения, которые создаются под мобильные платформы и обладают определенными особенностями для удобной работы на телефонах, планшетах и т.д.
Соответственно немобильные приложения — для немобильных платформ.

Фактически вы можете использовать хоть все три модели одновременно. Единственное — понятие «десктопное» приложение может не очень вязаться с «мобильными» приложениями, но просто потому что первое понятие стало ассоциироваться со стационарными компьютерами, которые тоже иногда называют десктопами.

То есть может быть клиентское мобильное браузерное приложение или даже клиентское мобильное десктопное приложение.

Может быть вам поможет «Команда» и «Цепочка ответственности».