Существуют ли технические причины, чтобы избежать создания сильно запутанных зависимостей пакетов в больших проектах Java?

Question

Я новичок в современных Java-компиляторах и виртуальных машинах, поэтому мне любопытно, с какими техническими проблемами сталкиваются крупные Java-проекты (более 5000 классов) во время компиляции и во время выполнения, когда растёт гордиев узел зависимостей пакетов?

В больших проектах на C ++ вы можете столкнуться с техническими проблемами (за исключением всех проблем, связанных с ремонтопригодностью), если в больших проектах вы отклонитесь от графика ациклических библиотек (или пакетов).

Некоторыепримеры

• компиляция может не хватить памяти, если большая часть дерева исходных текстов включена
• связывание может также выполняться, если включено слишком много архивов объектов (архивы объектов обычно коррелируют с пакетами в проектах C ++)

Эта проблема значительно усугубляется созданием встроенного шаблона.Современные рабочие станции не оборудованы для компиляции и связывания проекта, который объединяет большинство из 5000 значительных классов на любом этапе сборки.

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

Answer 1

1. Компилятор Java (javac) компилирует не все классы одновременно, а один за другим, динамически обнаруживая нескомпилированные или устаревшие .class файлы.

2. Нет ссылки .Вместо этого все файлы .class упакованы вместе в файл jar после компиляции.По сути, это сжатие ZIP, и этот шаг даже не требуется.

3. Компилятор Java довольно прост из-за простого синтаксиса и семантики языка.Например, не так много метапрограммирования, вывода типов и т. Д. Компилятор Scala работает намного медленнее, поскольку сам язык намного сложнее.

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

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

Answer 2

В Java нет такой вещи, как зависимости пакетов.Существуют только классовые (и интерфейсные) зависимости.При импорте пакета в Java вы только указываете компилятору, как разрешать имена (поэтому вам не нужно полностью определять каждый используемый вами класс или статическое имя импорта).

Круговые зависимости между тысячами классоввероятно, поставит компилятор на колени.