Алексей Черемисин

В вашем случае наверное подошел бы GraphQL - вот вводная статья https://habr.com/post/326986/
А вот имлементация на java - https://github.com/graphql-java/graphql-java
А вот статья для spring - www.baeldung.com/spring-graphql

Начните с изучения backend-фаеймворков. Например jooby.org или sparkjava.com
Делайте кучу REST/JSON сервисов, и дергайте их на фронтэнде.
В качестве базы возьмите mongodb.

Вот здесь почитайте - https://tproger.ru/translations/java8-concurrency-...

Вообще -то хорошо прятать такие вещи в resources, и загружать их относительно через getResource()
Вот здесь подробно написано - https://skipy-ru.livejournal.com/5343.html
Ну и текущий каталог можно получить так

Path currentRelativePath = Paths.get("");
String s = currentRelativePath.toAbsolutePath().toString();
System.out.println("Current relative path is: " + s);

Или попробовать так
System.getProperty("user.dir")
И javatutorialhq.com/java/example-source-code/io/fil...

Попробуйте вот это - https://github.com/Yasas/xbase4j

Вариантов простых несколько, но все они завязаны на сеть.
- поднять на шарпе простой http сервер, а в консольных программах к нему коннектиться и гонять туда-сюда json
- использовать чистые сокеты, что чревато изобретение собственного протокола, либо гонять по нит что-то типа protobuf
- использовать библиотеку zeromq, и через нее гонять сообщения
Мне наиболее симпатичны первый и третий варианты.

Как ни странно, итерировать группы совсем не обязательно!
1) группа у вас состоит из одного элемента. В вашем примере F и X - две группы, в которые нужно положить номера строк.
2) за один проход бежим по строкам и добавляем их в соответствующие группы термов, которые держим в hashtable, где ключом у нас сам терм, а значением - массив из номеров строк.
3) после того, как заполнили хеш, пробегаемся по нему один раз и смотрим, у кого длина массива больше единицы, это и будут исходные группы.

Если нам нужно дополнительно сформировать группы из двух-трех термов, то делает все тоже самое, но ключом ставим treeset из этих элементов.

import java.util.Arrays;
import java.util.HashMap;
import java.util.List;
import java.util.Map.Entry;
import java.util.TreeSet;

public class Groups {

	public static void main(String[] args) {
		String[] myData = {
				"F;I;J", 
				"F;X;A",
				"X;D;P",

				"A;B;C",
				"X;Y;Z",
				"J;A;Z",
				"U;V;W",
				"E;E;E",
				"D;F;G",
		};
		
		HashMap<String, TreeSet<Integer>> groups = new HashMap<String, TreeSet<Integer>>();
		
		for(int line=0; line< myData.length; line++ ) { // бежим по строкам
			
			List<String> terms = Arrays.asList(myData[line].split(";")); // разбиваем на термы
			
			for(String term: terms) { // пробегаем по термам
				TreeSet<Integer> group = groups.get(term); // выдергиваем группу
				
				if(group == null) { // если группы нет
					group = new TreeSet<Integer>();
					groups.put(term, group);
				}
				group.add(line); // добваляем строку
			}
		}
		
		// выводим результат
		for(Entry<String, TreeSet<Integer>> group: groups.entrySet()) {
			if(group.getValue().size() >1)
				System.out.printf("%s - %s\n", group.getKey().toString(), group.getValue().toString());
		}
	}
}

И результат

A - [1, 3, 5]
D - [2, 8]
F - [0, 1, 8]
J - [0, 5]
X - [1, 2, 4]
Z - [4, 5]

Вот я, как раз сбежал обратно на яву после 8 лет программирования на python!
И несказанно этому доволен - java8 стала очень и очень приятная, ну а бонусом прирост в скорости на моем приложении - 200х!
И так, как минимум рекомендую для web посмотреть jooby.org, sparkjava.org и конечно же spring boot.
На jooby как раз пишем маркет, очень весело и современно.
Да, на котлин пока не смотрел.

Координаты, это условные точки широты и долготы на поверхности шара. К метрам и километрам они имеют отношение только при пересчете на поверхность шара. Считают обычно по формуле гаверсинусов. Подробно описано здесь - gis-lab.info/qa/great-circles.html
На больших расстояниях может давать погрешность в 20-30 километров - расстояние от Москвы до Вашингтона например.
Для более точных расчетов используют модель геоида - упрощенной модели Земли, но и формулы там совершенно другие.

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

Ух, сколько кода... Рекомендую сесси. хибернейта класть в servlet-filter, здесь ее открывать, и тут же ее закрывать.
Стек вызовов у вас будет следующий

filter ->
   -> servler
       hibenate
   <- servlet
filter

Примерно так - https://gist.github.com/mccxj/146009

Вся и идея spring и ему подобных в технологиях DI и IoC.
Первая технология DI - Dependency Injection - внедрение зависимостей. Смысл следующий, пусть у нас есть класс, который зависит от другого класса, тогда контейнер автоматически найдет все зависимости и сам проинициализирует нужный класс. Пример: пусть у нас есть интерфейс "Фрукт", класс "Яблоко", интерфейс "Паразит", класс "Червяк". В класса "Яблоко" указываем в одном из методов или конструкторе зависимость от интерфейса "Паразит". Теперь положим в контейнер классы "Червяк" и "Яблоко", и попросим контейнер создать дать нам инстанс класса "Яблоко".
Контейнер выполнит следующие действия:
- посмотрит, что без класса, реализующего интерфейс "Паразит", он не может создать "Яблоко".
- посмотрит на зарегистрированные классы, не реализует ли кто интерфейс "Паразит" и обнаружит класс "Червяк"
- создаст инстанс класса "Червяк"
- создаст инстанс класса "Яблоко" и передаст ему инстанс класса "Червяк"
- отдаст созданный инстанс "Яблоко" нам.

Теперь мы можем создать класс "Ева" с зависимостью от интерфейса "Фрукт", положить его в контейнер, и положить в контейнер класс "Адам" с зависимостью от "Ева" и попросить создать нам инстанс класса "Адам" :-)

MutablePicoContainer pico = new DefaultPicoContainer();
pico.addComponent(Fruit.class);
pico.addComponent(Worm.class);
pico.addComponent(Eve.class);
pico.addComponent(Adam.class);
.....
Adam adam = pico.getComponent(Adam.class);

Вторая технология IoC - Inversion of Control - контроль управления - это как раз и есть одна из реализаций принципа DI, когда внедрение зависимостей происходит через посредника - фреймворк.

Легче всего разобраться с этим (а уж потом переходить к spring) - поработать с простыми контейнерами типа picocontainer , nanocontainer и guice.
- picocontainer.com/introduction.html
- https://github.com/google/guice

В любом случае вариантов как минимум два, или заглядывать вперед в потоке, или заново переоткрывать.
Можно поступить хитрым образом - использовать https://docs.oracle.com/javase/7/docs/api/java/io/... и/или GSON stream API.

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

Во втором случае можно прочитать только первый элемент, найти нужные нам маркеры и например переоткрыть файл заново - https://memorynotfound.com/gson-streaming-api-read...

На яве есть проект - apache tika tika.apache.org
Как раз для этих целей.
Вот здесь есть туториал https://www.tutorialspoint.com/tika/index.htm
Сама тика поддерживает парсинг текста и метаданных из приблизительно 15к разных форматов.

Полнейшая глупость! На данный момент: а по хорошему уже лет 10 минимум, существует куча асинхронных фреймворков и сетевых библиотек, которые работают ровно на том же самом принципе, как и nodejs.
Примеров, у нас их есть:
- фреймворки jooby.org, sparkjava, springboot
- библиотеки (серверы) netty, undertow, akka
По производительности ничуть не уступают nodejs.

Ну а как все это работает? Есть два вида программирования, которые можно совмещать:
Старый и много кем используемый
- сервер ждет сетевое соединение
- как только соединение произошло, сервер запускает процесс/поток и ему передает открытое соединение.
В этом случае мы ограничены количеством потоков/процессов в системе, имеем большой оверхед на создание процесса/потока. Зато нам не нужно сильно заботиться о работе с сокетами.
Новый хайповый/модерновый
- при старте в сервере региструются обработчики данных (наши сервисы/приложения)
- сервер открывает сокет и слушает все открытые им ранее сокеты, висит в ожидании события прихода/передачи данных на методе select/poll/epoll или побобном.
- как только сервер получил ответ, он вызывает зарегистрированный обработчик и передает туда порцию полученных данных, принимает эти данные обратно и и отправляет в сеть на нужное соединение
В этом случае сервер работает в один поток, просто последовательно вызывая обработчики и отдавая им данные. Быстро, очень быстро, ловко, нет накладных расходов. Зато, если какой обработчик пытается сделать блокирующую операцию - виснут все остальные обработчики, поэтому обработчики с сервером общаются сообщениями и стараются не занимать много процессорных ресурсов. Программирование получается сложное.

Также можно совмещать эти два подхода, делая и пул потоков и работая в асинхронном режиме.

На почитать сюда например - https://ru.wikipedia.org/wiki/Epoll