几天前，当我不得不将C ++文件引入Java项目时，我遇到了一个问题。它首先需要测量Java进程的CPU使用率，并且决定使用JNI来调用用C编写的本机库（Unix机器上的共享库）。问题是找到一个合适的位置将C文件放入源存储库（顺便说一下Clearcase），它只包含Java文件。
我想到了几个选择：
（a）创建一个单独的目录，用于将C文件（特别是一个.h文件和一个.c文件）放在源代码库的顶部，如：
/的VOB / myProduct的/ javasrc
/的VOB / myProduct的/ cppsrc
我不喜欢这个，因为我只有两个C文件，在这样的语言级别拆分源代码库似乎很奇怪。如果项目的大部分内容在C ++和Java中或多或少地写得相同，那么这可能没问题。
（b）将C文件放入使用它的Java包中。
我在/ vobs / myproduct / com / mycompany / myproduct / util /中调用了Java类，C文件也在那里。
我不喜欢这个，因为我认为C文件不属于Java包。
以前有人解决过这样的问题吗？通常，在组织混合两种或更多语言的代码库时，要遵循什么是一个好策略？
更新：我没有任何计划在我的项目中使用任何C或C ++，也许是一些Jython，但是你永远不知道我的客户何时需要一个只能通过使用C解决的功能或者最好用C解决的功能。
“我不喜欢这个，因为我只有两个C文件，在这样的语言级别拆分源代码库似乎很奇怪”
为什么它看起来很奇怪？考虑这个项目：
PROJECT1的\ src \ java中
PROJECT1的\ src \ CPP
PROJECT1的\ src \蟒蛇
或者，如果您决定将内容拆分为模块：
PROJECT1 \模块1的\ src \ java中
PROJECT1 \模块1的\ src \ CPP
PROJECT1 \模块2的\ src \ java中
PROJECT1 \模块2的\ src \蟒蛇
我想这是个人品味的问题，但上述结构相当普遍，我认为一旦你习惯了它就会很好用。
“我不喜欢这个，因为我只有两个C文件，在这样的语言级别拆分源代码库似乎很奇怪”
为什么它看起来很奇怪？考虑这个项目：
PROJECT1的\ src \ java中
PROJECT1的\ src \ CPP
PROJECT1的\ src \蟒蛇
或者，如果您决定将内容拆分为模块：
PROJECT1 \模块1的\ src \ java中
PROJECT1 \模块1的\ src \ CPP
PROJECT1 \模块2的\ src \ java中
PROJECT1 \模块2的\ src \蟒蛇
我想这是个人品味的问题，但上述结构相当普遍，我认为一旦你习惯了它就会很好用。
Maven为Web应用程序生成的默认布局是 src/main/java， src/test/java， src/main/resources，和 src/test/resources。我认为它会默认添加 src/main/cpp 和 src/test/cpp 同样。这对我来说似乎是一个不错的约定。
将它们保存在单独的文件夹中是个好主意。它比查找C文件的Java包更容易找到它，并且它还允许在将来添加更多C代码而不必在以后全部移动它。
我个人将两者分开，甚至可能分成他们自己独立的项目，但那时他们都是分开的事情，就像你不会在同一个班级中放入两个不同的概念一样。当它们都触及相同的概念区域时，它会变得更加模糊。当然，在构建代码时总会出现问题，例如是否可以将其置于结构b）中，而不需要做各种各样的技巧来编译代码？您是否计划在项目中使用更多C，在这种情况下，如果您遵循相同的模式，C文件将遍布您的项目...
就个人分裂语言解决方案而言，我会将它们保存在单独的项目或文件夹中。
查看问题的一种方法是像对待任何其他第三方API一样对待C类。在java代码中输出依赖项（即避免直接调用）以避免紧密耦合并将C源保存在java的单独项目/文件夹中。
我们使用不同的术语。有一个产品不是项目。该产品由Java工作区和C / C ++工作区组成，每个工作区可从不同的IDE加载。最终，如果您使用同一个IDE，则只有一个工作区。
每个工作区由几个项目组成。每个项目都有自己的文件夹结构（src，bin，res，e.t.c）。因此，如果它只是一个工作空间，那么最好至少有一个Java和一个C / 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 ...
这样，您最终可以为每个项目使用一个相同的文件夹结构，这样更加一致。基本上这只是一个抽象层次 - 将产品划分为不同的相关项目。
在这种情况下，所讨论的文件不仅仅是一种不同的语言，而且还作为一个单独的程序运行，该程序通过定义的接口进行交互。这意味着源文件可以作为单独的项目处理，因此保存在其他地方。
.NET项目中的情况不同，它将C＃和ASP.NET（例如）混合在一个代码库中。在这种情况下，人们如何组织代码？