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

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

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

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

/ВОБ/MyProduct/javasrc /ВОБ/MyProduct/cppsrc

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

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

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

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

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

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

Ответ 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\питон

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

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

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

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

Ответ 7

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

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