Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

JavaCPP sometimes deletes class files

21 views
Skip to first unread message

Davidson, Josh

unread,
Nov 7, 2022, 12:02:32 PM11/7/22
to javacpp...@googlegroups.com
I have a C++ project that uses JavaCPP for Java bindings. The build script for generating the binding code resembles something like:

javac -cp ${javacpp}:${classpath} -d ${classpath} ${src}/com/foo/bindings/ClassConfig.java
java -jar ${javacpp} -nodelete -classpath ${classpath} -d ${src} com.foo.bindings.ClassConfig

If a re-run a build where class files are exist ${classpath}/com/foo/bindings the invocation of the 2nd command will sometimes result in the entire ${classpath}/com/foo/bindings directory getting deleted. It’s a bit random where sometimes it’s running JavaCPP on first compiled binding class that results in the directory getting blown away and sometimes the first pair of commands go through cleanly and it’s a subsequent invocation of JavaCPP on a later binding class (generally/always the 2nd) that results in the directory getting removed. When I use strace on the second command, I don’t see any deletes in the output. Oddly the directory doesn’t seem to get deleted directly after the process exists, but maybe up to a second later. If I add a sleep after the JavaCPP invocation, and monitor the directory, it gets deleted fairly quickly after the java process exits and before anything else runs.

Any idea why this might be happening? I can probably workaround this by deleting the directory that houses the binding class files before starting to generate them, but I’d like to understand what’s going on. I’m using JavaCPP 1.5.4 on Linux.

Samuel Audet

unread,
Nov 7, 2022, 7:30:03 PM11/7/22
to javacpp...@googlegroups.com, Davidson, Josh
Are you sure this is happening when JavaCPP runs, not javac? The
compiler may remove existing class files when compiling new ones, but if
it fails, it will not magically undelete them. Moreover, for that
reason, outputting files to the class path is not a good idea. The
compiler might very well load all the classes it needs from the class
path before removing anything, but that's not guaranteed. You're in
undefined behavior territory here.

Other than that, why is the output directory set to the source
directory? If someone activates the "clean" option, that will get deleted.

Samuel

Samuel Audet

unread,
Nov 9, 2022, 5:32:57 AM11/9/22
to javacpp...@googlegroups.com, Davidson, Josh
In any case, if you're able to reproduce this outside your build
process, I'll be happy to take a look at it and see how we can fix this.
It doesn't sound like an issue related to JavaCPP though.

Samuel

josh.d...@lmco.com

unread,
Nov 10, 2022, 12:26:12 PM11/10/22
to javacpp
Sorry, came down with the flu.  I debated even posting this when strace wasn't showing the java process deleting the directory and it seemed to disappear very shortly after java exited.  It was definitely not getting deleted by javac, though (added a sleep between those two steps to confirm). I'm still not sure exactly what the culprit was, but I suspect it may have been vscode.  I had a remote workspace opened on the same directory, although I wasn't working it at the time.  However, at one point I switched into it, updated all plugins and restarted it and then magically no longer had the delete problems.

I didn't realize the -clean option of javacpp nuked the entire output directory.  However, the invocations of javacpp are abstracted away through the project's mvn pom file.  You are right we have had problems of compiling classes to the project's classpath when things have been renamed, but otherwise it hasn't been a major issue.  Is the common approach to keep javacpp generated source into a separate standalone project or create multiple source/classpath roots within a project?  Most of the additional hand code is providing facades around the generated classes (i.e. directly coupled to the bindings).

Samuel Audet

unread,
Nov 11, 2022, 7:56:30 PM11/11/22
to javacpp...@googlegroups.com, josh.d...@lmco.com
If it's all managed by Maven, it's not a problem to let compile all
source files into the default target/classes, that's fine. But yes it's
better to put the source files generated by JavaCPP in separate
directory to make it easy to clean them. That's how it's being done in
the JavaCPP Presets, so you can use that as reference:
https://github.com/bytedeco/javacpp-presets

Samuel
Reply all
Reply to author
Forward
0 new messages