混合两种或多种语言（例如 Java 和 C++）时组织源代码库
几天前，当我必须将 C++ 文件引入 Java 项目时，我遇到了一个问题。 一开始需要测量 Java 进程的 CPU 使用情况，并决定采用 JNI 调用用 C 编写的本机库（Unix 机器上的共享库）。问题是在仅由 Java 文件组成的源存储库（顺便说一下 Clearcase）中找到一个适当的位置来放置 C 文件。
我想到了几种替代方案：
(a) 创建一个单独的目录，用于将 C 文件（具体来说，一个 .h 文件和一个 .c 文件）放在源代码库的顶部，例如：
/vobs/myproduct/javasrc /vobs/myproduct/cppsrc
我不喜欢这个，因为我只有两个 C 文件，而且像这样在语言级别拆分源代码库似乎很奇怪。 如果项目的大部分内容或多或少都是用 C++ 和 Java 编写的，那么这可能没问题。
(b) 将 C 文件放入使用它的 Java 包中。
我在 /vobs/myproduct/com/mycompany/myproduct/util/ 中有调用 Java 类，C 文件也位于其中。
我也不喜欢这个，因为我认为 C 文件不属于 Java 包。
以前有人解决过这样的问题吗？ 一般来说，在组织混合两种或多种语言的代码库时，应该遵循什么好策略？
更新：我没有任何计划在我的项目中使用任何 C 或 C++，也许是一些 Jython，但你永远不知道我的客户何时需要一个只能通过使用 C 来解决或最好通过使用 C 来解决的功能。
I ran into a problem a few days ago when I had to introduce C++ files into a Java project. It started with a need to measure the CPU usage of the Java process and it was decided that the way to go was to use JNI to call out to a native library (a shared library on a Unix machine) written in C. The problem was to find an appropriate place to put the C files in the source repository (incidentally Clearcase) which consists of only Java files.
I thought of a couple of alternatives:
(a) Create a separate directory for putting the C files (specifically, one .h file and one .c file) at the top of the source base like:
/vobs/myproduct/javasrc
/vobs/myproduct/cppsrc
I didn't like this because I have only two C files and it seemed very odd to split the source base at the language level like this. Had substantial portions of the project been written more or less equally in C++ and Java, this could be okay.
(b) Put the C files into the Java package that uses it.
I have the calling Java classes in /vobs/myproduct/com/mycompany/myproduct/util/ and the C files also go in there.
I didn't like this either because I think the C files just don't belong in the Java package.
Has anybody solved a problem like this before? Generally, what's a good strategy to follow when organizing codebase that mixes two or more languages?
Update: I don't have any plan to use any C or C++ in my project, some Jython perhaps, but you never know when my customers need a feature that can be solved only by using C or best solved by using C.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
在这种情况下，相关文件不仅是不同的语言，而且还作为通过定义的接口进行交互的单独程序运行。 这意味着源文件可以被视为一个单独的项目，因此可以保存在其他地方。
.NET 项目的情况有所不同，它在一个代码库中混合了 C# 和 ASP.NET（例如）。 在这种情况下人们如何组织他们的代码？
In this case, the files in question are not just a different language, but also run as a separate program that interacts through a defined interface. This means that the source files can be treated as a separate project, and therefore kept elsewhere.
The case is different in .NET projects which mix C# and ASP.NET (for example) within one codebase. How do people organise their code in such cases?
让我们使用不同的术语。 有一种产品不是项目。 该产品由 Java 工作区和 C/C++ 工作区组成，每个工作区都可以从不同的 IDE 加载。 最终，如果您使用同一个 IDE，则将只有一个工作区。
每个工作区由多个项目组成。 每个项目都有自己的文件夹结构（src、bin、res 等）。 因此，如果只有一个工作区，那么最好内部至少有一个 Java 和一个 C/C++ 项目，每个项目都有不同的编译/运行/调试/输出/... 设置。
因此，我会使用：
这样您最终可以为每个项目使用一个相同的文件夹结构，这更加一致。 基本上，这只是又一层抽象——将产品划分为不同的相关项目。
Let's use different terminology. There is one product which is not project. The product consist of Java workspace and C/C++ workspace, each loadable from the different IDE. Eventually if you use one and the same IDE there will be only one workspace.
Each workspace consists of several projects. Each project has its own folder structure (src, bin, res, e.t.c). So in case it is only one workspace, then it is better to have at least one Java and one C/C++ project inside, each with different compile/run/debug/output/... settings.
So, I would use:
This way you can use eventually one and the same folder structure for each project, which is more consistent. Basically this is just one more level of abstraction - dividing the product to different related projects.
Maven 生成的 Web 应用程序的默认布局为
src/main/java、src/test/java、src/main/resources和src/test/resources。 我假设它也会默认添加 src/main/cpp 和 src/test/cpp 。 对我来说，这似乎是一个足够体面的惯例。The default Maven-generated layout for web apps is
src/main/java,src/test/java,src/main/resources, andsrc/test/resources. I would assume that it would default to addingsrc/main/cppandsrc/test/cppas well. This seems like a decent enough convention to me.“我不喜欢这个，因为我只有两个 C 文件，而且像这样在语言级别拆分源代码库似乎很奇怪”
为什么这看起来很奇怪？ 考虑这个项目：
或者，如果您决定将事物分成模块：
我想这是个人喜好的问题，但是上面的结构相当常见，而且我认为一旦习惯了它就可以很好地工作。
"I didn't like this because I have only two C files and it seemed very odd to split the source base at the language level like this"
Why does it seem odd? Consider this project:
Or, if you decide to split things up into modules:
I guess it's a matter of personal taste, but the above structure is fairly common, and I think it works quite well once you get used to it.
就我个人而言，对于拆分语言解决方案，我会将它们保存在单独的项目或文件夹中。
看待问题的一种方法是将 C 类视为任何其他第三方 API。 在 java 代码中连接出依赖关系（即避免直接调用），以避免紧密耦合，并将 C 源代码保存在与 java.util.concurrent.java 文件不同的项目/文件夹中。
Personally in the case of split language solutions, I would keep them in seperate projects or folders.
One way of looking at the problem is to treat the C classes like any other third party API. Interface out the dependancies (i.e. avoid direct calls) in your java code to avoid tight coupling and keep the C source in a seperate project/folder from the java.
就我个人而言，我会将两者分开，甚至可能分成他们自己的单独项目，但那是当它们都是单独的东西时，就像你不会将两个不同的概念放在同一个类中一样。 当他们都触及相同的概念领域时，事情就会变得更加模糊。 当然，在构建代码时总是存在问题，例如是否可以将其放入结构 b) 中，而不需要执行各种技巧来编译它？ 您是否计划在项目中使用更多 C，在这种情况下，如果您遵循相同的模式，C 文件将遍布您的项目......
Personally I'd separate the two, possibly even into their own separate projects, but that's when they are both separate things, much like you wouldn't put two different concepts in the same class. It's get much vaguer when they both touch the same conceptual area. Ofcourse there's always issues when it comes to building the code, is putting it in structure b) possible for instance without needing to do all sorts of tricks to get it to compile? Are you planning on using more C in the project, in which case the C files would get spread all over your project if you follow the same pattern ...
将它们保存在单独的文件夹中是一个好主意。 与在 Java 包中搜索 C 文件相比，它更容易找到，并且还允许将来添加更多 C 代码，而无需稍后移动它们。
Keeping them in separate folders is a good idea. It makes it easier to find than searching Java packages for the C files, and it also allows for the possibility of adding more C code in the future without having to move it all around later.