There has been a comment in one of the JCuda GitHub issues :
Actually more important is that I suggest to merge/make obsolete this project in favor of JavaCPP and propose to developers of this project and jopencl as well to focus on JavaCPP stuff as it has much wider focus… just proposal making sense from my perspective.
This proposal is not entirely new: Two years ago, @saudet started a thread about his CUDA bindings based on JavaCPP , and we had a nice and interesting discussion (some of which went into technical details that may not be immediately be relevant here, but are of course related to some of the advantages and disadvantages of both solutions)
In general, I agree that a “universal” solution for accessing CUDA from Java would be desirable. And it should be obvious that JavaCPP tackles the problem of accessing C++ libraries from Java in the most generic sense, which can have many obvious advantages: The solutions generated with JavaCPP can be …
- more generic solutions and interfaces
- more robust due to being applied to vastly different application patterns
- Important: they can be interoperable, because they are built on the same technical basis
- Also important: They are mostly auto-generated, and can be updated far more quickly than my manual bindings
In contrast to that, JCuda went through several evolutionary stages. Originally, I started with naively creating bindings for CUBLAS, which seemed to be a low-hanging fruit due to the simple API and the huge performance improvements that it promised. Later, I added bindings for CUFFT. But before creating more individual bindings for the other CUDA libraries, I decided to put this on a common basis, namely JCuda.
Of course, this history implies some legacy. I did not have much experience with JNI before that, and the nature of CUDA bears some really challenging points. If I could start again, from scratch, I would solve some things differently. This mainly refers to all aspects of the memory handling (basically everything surrounding the Pointer
class), but also to other details. In constrast to the manual JCuda bindings, JavaCPP is so generic that certain problems simply do not appear in the first place. (And I probably would not have started JCublas or JCuda if JavaCPP had been available 8 years earlier)
However, I will not abandon JCuda so quickly. I know that there are “~several” users of JCuda out there - although I don’t have a precise overview here. I only know that from support requests, and by some (scientific) papers/theses that are citing JCuda. (Some of them are erroneously citing a paper about a library called JCUDA, which is unrelated to JCuda, but the code snippets in the papers indicate that they are actually using JCuda and not JCUDA). And although it may sound a bit balky, defiant or pathetic: I consider it as a responsibility towards these users to continue to work on JCuda.
Time will show whether or not the two approaches can converge or how they will coexist. In the “best” case, they could both become obsolete, namely when an interoperability layer for accessing native libraries from Java is built into the language/standard API/JVM itself. This might also happen on a different level of abstraction. Although the project Sumatra is basically abandoned, the project Panama is still active, and only a few days ago, there has been a post about Experimental support for CUDA. This looks quite promising.
(I could now also mention some of the “advantages” that JCuda has in contrast to JavaCPP. Some of them would be subjective, like the fact that the manual 1:1 mapping of the CUDA API may allow a bit more control over what the API will look like (at the cost of slower update cycles). Others might become obsolete if JavaCPP-CUDA gained more attention - for example, the fact that there are actual samples that show how the library may be used to accomplish certain tasks. But I agree that these “advantages” do not necessarily outweigh the lower-level technical advantages that JavaCPP and its automated code-generation have, compared to the hand-crafted JNI bindings of JCuda).