Организация базы исходного кода при смешивании двух или более языков (например, Java и C++)

Question

Я столкнулся с проблемой несколько дней назад, когда мне пришлось вводить файлы C++ в проект Java. Это началось с необходимости измерить загрузку процессора Java-процессом, и было решено, что нужно использовать JNI для вызова нативной библиотеки (общей библиотеки на Unix-машине), написанной на C. Проблема заключалась в том, что найти подходящее место для размещения файлов C в исходном хранилище (кстати, в Clearcase), которое состоит только из файлов Java.

Я подумал о паре альтернатив:

(a) Создайте отдельный каталог для размещения файлов C (в частности, одного.h файла и одного.c файла) в верхней части исходной базы, например:

/ vobs / myproduct / javasrc / vobs / myproduct / cppsrc

Мне это не понравилось, потому что у меня есть только два файла C, и было очень странно разделить исходную базу на уровне языка, как это. Если бы существенные части проекта были написаны более или менее одинаково на C++ и Java, это было бы хорошо.

(b) Поместите файлы C в пакет Java, который их использует.

У меня есть вызывающие Java-классы в / vobs / myproduct / com / mycompany / myproduct / util /, и файлы C также находятся там.

Мне это тоже не понравилось, потому что я думаю, что файлы C просто не входят в пакет Java.

Кто-нибудь решал такую ​​проблему раньше? Вообще, какой хорошей стратегии следует придерживаться при организации кодовой базы, которая смешивает два или более языков?

Обновление: у меня нет никакого плана использовать какой-либо C или C++ в моем проекте, возможно, некоторые Jython, но вы никогда не знаете, когда моим клиентам нужна функция, которая может быть решена только с помощью C или лучше всего решается с помощью C.

Answer 1

"Мне это не понравилось, потому что у меня есть только два файла C, и было очень странно разделить исходную базу на уровне языка, как это"

Почему это кажется странным? Рассмотрим этот проект:

  project1 \ SRC \ Java
  project1 \ SRC \ CPP
  project1 \ SRC \ питон

Или, если вы решили разделить вещи на модули:

  project1 \ module1 \ SRC \ Java
  project1 \ module1 \ SRC \ CPP
  project1 \ module2 \ SRC \ Java
  project1 \ module2 \ SRC \ питон

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

Answer 2

Созданный Maven макет по умолчанию для веб-приложений: src/main/java, src/test/java, src/main/resources, а также src/test/resources, Я бы предположил, что это будет по умолчанию для добавления src/main/cpp а также src/test/cpp также. Это кажется достаточно приличным соглашением для меня.

Answer 3

Хранить их в отдельных папках - хорошая идея. Это облегчает поиск, чем поиск пакетов Java для C-файлов, а также дает возможность добавлять больше C-кода в будущем, не перемещая его позже.

Answer 4

Давайте использовать другую терминологию. Есть один продукт, который не является проектом. Продукт состоит из рабочей области Java и рабочей области C/C++, каждая из которых загружается из своей среды IDE. В конце концов, если вы используете одну и ту же IDE, будет только одно рабочее пространство. Каждое рабочее пространство состоит из нескольких проектов. Каждый проект имеет свою собственную структуру папок (src, bin, res и т. Д.). Так что, если это только одно рабочее пространство, лучше иметь хотя бы один Java и один проект C/C++, каждый с разными настройками compile/run/debug/output/....

Итак, я бы использовал:

Product/Workspace(1)/JavaProject1/src 
Product/Workspace(1)/JavaProject2/src 
Product/Workspace(1 or 2)/CPPproject1/src 
Product/Workspace(1 or 2)/CPPproject2/src ...

Таким образом, вы можете использовать одну и ту же структуру папок для каждого проекта, что более согласованно. По сути, это всего лишь еще один уровень абстракции - разделение продукта на различные связанные проекты.

Answer 5

Лично я бы разделил их, возможно, даже на их собственные отдельные проекты, но именно тогда они являются отдельными вещами, как если бы вы не поместили две разные концепции в один класс. Это становится намного более неопределенным, когда они оба касаются одной и той же концептуальной области. Конечно, всегда есть проблемы, когда дело доходит до сборки кода, возможно ли, например, поместить его в структуру б), не прибегая к всяким трюкам для его компиляции? Планируете ли вы использовать больше C в проекте, и в этом случае файлы C будут распространяться по всему проекту, если вы будете следовать той же схеме...

Answer 6

Лично в случае решений на разных языках я бы держал их в отдельных проектах или папках.

Один из способов решения этой проблемы состоит в том, чтобы относиться к классам C как к любому другому стороннему API. Интерфейс обеспечивает зависимости (т.е. избегает прямых вызовов) в вашем Java-коде, чтобы избежать тесной связи и хранить исходный код C в отдельном проекте / папке из Java.

Answer 7

В этом случае речь идет не только о другом языке, но и как о отдельной программе, взаимодействующей через определенный интерфейс. Это означает, что исходные файлы могут рассматриваться как отдельный проект и, следовательно, храниться в другом месте.

Другой случай в проектах.NET, которые смешивают C# и ASP.NET (например) в одной кодовой базе. Как люди организовывают свой код в таких случаях?