Power

Я думаю, вы говорите об отсутствии поддержки SNI (в java < 7). Попробуйте подключиться к https://bob.sni.velox.ch/.

Оба первичны. Надо проектировать сущности и базу одновременно. Ибо именно с сущностями вам работать в коде, так что они должны быть удобны; но и над представлением их в БД тоже надо думать, чтобы не получилось неэффективное решение.
Лично я сначала описываю сущности в коде, потом запускаю по ним автогенератор схемы БД и проверяю результат. Если меня всё устраивает - OK, если нет, правлю сущности, подпиливаю аннотации и повторяю процесс.

Такое ощущение, что у вас томкат не запущен или запущен не на порту 8080.

Читайте про то, что такое checked exceptions и unchecked exceptions.

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

А в чём проблема? Склеивайте всё в один поток и читайте его построчно. Если строка начинается с $ - используйте её.

Из опыта: в java не используются элементы венгерской нотации, в том числе, имя интерфейса не имеет префикса "I". При реализации интерфейса классам иногда даётся суффикс "Impl" (но не всегда; скорее всего, только тогда, когда единственное назначение класса - это реализация интерфейса).
Как обосновать, я не знаю, скорее всего, так исторически сложилось. Есть некоторые общие coding conventions от Sun, но их используют скорее как рекомендации, а не как строгие правила. Ну и все нормальные IDE (по крайней мере, для java) способны показать тип любого идентификатора, так что указывать это в имени избыточно.

Signature signature2 = Signature.getInstance(publicKey.getAlgorithm(), IolaProvider.PROVIDER_NAME);

А вы уверены, что алгоритм открытого ключа совпадает с алгоритмом подписи?

ThreadLocal

Вам нужно подключить зависимость joda-time-jsptags.

Для junior неплохо. Из того, что я вижу, существенные минусы:

• SQL injection в https://github.com/un1acker/employeeProject/blob/m... : во-первых, поле whatSearch (сомнительное название) надо проверять по списку допустимых значений (фиксированному или получаемому через reflection из класса Employee), а для построения запроса лучше использовать что-то типа Criteria; во-вторых, для searchBy (тоже сомнительное название) надо использовать prepared statements (это которые с подстановками в стиле "where E.field = ?"), а в данном случае лучше тот же Criteria
• множественные XSS в https://github.com/un1acker/employeeProject/blob/m... - нужен какой-то js-шаблонизатор или очень аккуратное манипулирование DOM-ом
• отсутствует валидация данных, например, что возраст хотя бы неотрицателен
• delete делается GET-запросом (GET-запросы должны использоваться тогда и только тогда, когда пользователь не намеревается что-то менять)
• сервис EmployeeService бесполезен - он все методы сразу делегирует EmployeeDAO

Несущественные минусы:

• лишние файлы в проекте (.idea/, target/, empl.iml)
• в классе Employee лишние аннотации @Table(name="employee") и @Column(name="...") - это сразу делается настройкой NamingStrategy (возможно, это даже настроено по умолчанию)
• в классе Employee оба конструктора не нужны - пустой генерируется автоматически (если нет других), а полный не используется
• в интерфейсах не надо у методов писать public - они и так public (и более того, это нельзя поменять)
• maven (gradle рулит :)

У вас все поля классов объявлены с модификатором static, а должны быть без него.
И в коде у вас странные дублирования и лишний код, например, вместо

while (true) {
			try {
				setConnect(server.accept());
			} catch (IOException e) {
				e.printStackTrace();
			}
		
			new Thread(new IncomingHandler(getConnect())).start();
		}

должно быть что-то вроде

while (true) {
			try {
				Socket accepted = server.accept();
				new Thread(new IncomingHandler(accepted)).start();
			} catch (IOException e) {
				e.printStackTrace();
			}
		}

и тогда не нужны методы

public static Socket getConnect() {
		return connect;
	}

	public static void setConnect(Socket connect) {
		Server.connect = connect;
	}

Отличный выбор точек! Они лежат на одной прямой, так что площадь действительно равна 0.

Сведения о памяти можно ещё с помощью jstat смотреть. Это такая консольная утилита, которая позволяет подключиться к любому запущенному java-процессу (только запускать её обязательно от имени того же пользователя, от которого java запущена).
Эти же сведения умеют показывать всякие графические visualvm и jconsole.
Но то, что вы там увидите, - это потребеление, в которое входят в том числе объекты самой JVM и несобранный мусор.
А чтобы смотреть подробности и "чистое" потребление, нужен профилировщик (visualvm и jconsole это тоже умеют).

Сам класс (мета-сущность - инстанс класса java.lang.Class<OuterClass.InnerStaticClass>) существует в единственном экземпляре, но это относится к любому классу (если не углубляться в класслоадеры). А вот инстансов класса OuterClass.InnerStaticClass можно сделать сколько угодно (на это влияет доступность конструкторов, как обычно):
new OuterClass.InnerStaticClass();
Единственное отличие внутреннего статического класса от внутреннего нестатического - ему не требуется инстанс окружающего класса для создания (ну и после создания он не имеет ссылки на этот самый инстанс окружающего класса):

new OuterClass.InnerNonStaticClass(); // нельзя
OuterClass o = new OuterClass();
new o.InnerNonStaticClass(); // можно
new OuterClass.InnerStaticClass(); // а в случае со статическим классом так можно

Не путайте статический класс со статическими полями класса.