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

Question

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

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

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

/ ВОБ / MyProduct / javasrc / ВОБ / 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\python

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

  project1\module1\src\java
  project1\module1\src\cpp
  project1\module2\src\java
  project1\module2\src\python

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

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

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

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

Answer 5

Давайте использовать другую терминологию. Есть один продукт, который не является проектом. Продукт состоит из рабочей области Java и рабочей области C / C ++, каждая из которых загружается из своей среды IDE. В конце концов, если вы используете одну и ту же IDE, будет только одно рабочее пространство. Каждое рабочее пространство состоит из нескольких проектов. Каждый проект имеет свою собственную структуру папок (src, bin, res, e.t.c). Так что, если это только одно рабочее пространство, лучше иметь хотя бы один 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 6

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

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

Answer 7

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