Hacking JavaCPP in Eclipse

[nyholku]

FYI

I like to examine and try out stuff in JavaCPP using Eclipse.

If you want to do that you can find some hints in my repo in this branch:

https://github.com/nyholku/javacpp/tree/eclipse-tooling

I don't like Maven builds for hacking/development because it so slow that it is a ball and a chain.

So what I do I download all the jars manually from Maven Central (they are in my repo now) and just add them to the debug configuration on to the class path.

The current (as of today) list of jars is

junit-4.13.2.jar
maven-artifact-3.8.4.jar
maven-core-3.0.jar
maven-model-3.8.4.jar
maven-plugin-annotations-3.6.2.jar
maven-plugin-api-3.8.4.jar
osgi.annotation-7.0.0.jar
slf4j-api-1.7.33.jar
slf4j-simple-1.7.32.jar

Then I create a Java class (below) with main that calls on Builder main so that I don't have to go to the command line to execute anything.

import org.bytedeco.javacpp.tools.Builder;

//NOTE! requires that current directory is set to what ever is necessary when you run JavaCPP from the commandline ,
//      AFAIK this cannot be set in Java code
//      In Eclipse set it in Debug Configurations / Arguments tab

public class DebugJavaCPP {
	public static void main(String[] args) {
		try {
			String platform = "/Users/nyholku/javacpp/src/main/resources/org/bytedeco/javacpp/properties/macosx-x86_64.properties";
			String[] args1 = { "-propertyfile", platform, "occ/TKernelConfig.java" };
			Builder.main(args1);
			String[] args2 = { "-propertyfile", platform, "-nodelete", "occ/TKernel.java"};
			Builder.main(args2);
		} catch (Exception e) {
			e.printStackTrace();
		}
	}
}

For above to work it is essential that the current directory for the debug configuration is set to the same directory as you would use if you would execute JavaCPP from the command line.

By doing what I advocate above I can just press CMD+F11 on Eclipse and the code start immediately with no compile step and I can use all Eclipse facilities to examine the code and runtime state.

There are probably easier ways to do above but I share what I do, tips are welcome.

I know, many people prefer and like IntelliJ and Maven and if you are happy with those, then that is great.

But for me and for hacking I find above works best for me.

wbr Kusti

[saudet]

If the only thing you dislike about Maven is the speed, I'd recommend using Gradle instead:
https://github.com/bytedeco/gradle-javacpp
But maybe you don't like that one for some other reasons...

[nyholku]

Thanks.

I dislike Mavan whole approach, but as long as it doesn't get in the way I don't really mind.

But for what I call hacking and exploring code the speed penalty is unbearable for me.

It gets the job done for consistent builds and packaging etc so not bad for production builds and distribution.

I've tried gradle and liked it better, but even that is too slow for my temperament. Maybe I just did not spend enough time with it to tune it for my liking. Or the Eclipse plugin got in the way or was not mature enough when I tried it. YMMV.

But basically what I want is instant gratification, I add something to the code the experiment or investigate / instrument and I want to execute it without any perceptible delay.

But that is just me. I've done my time with 20 min compile cycles and 15 min UV-EPROM erase and burn cycles and my remaining life feels too short to spend it on things like waiting anything. Not to mention what it does to concentration. I find that 15 sec is enough to start my mind wondering where I could spend the wait time.

Fortunately (?) everyone can use whatever tools they want if not dictated by employers. We can't all like same things and my 'post' here was just to share what little I had learn to be able to do what I wanted. So as to spare some other poor dev from re-inventing that.

[saudet]

Right, ok, anyway, JavaCPP was designed to be used programmatically, that's why the Gradle and Maven plugins are lean:
https://github.com/bytedeco/javacpp/blob/master/src/main/java/org/bytedeco/javacpp/tools/BuildMojo.java
https://github.com/bytedeco/gradle-javacpp/blob/master/src/main/java/org/bytedeco/gradle/javacpp/BuildTask.java
And that's how the tests are getting executed as well:
https://github.com/bytedeco/javacpp/blob/master/src/test/java/org/bytedeco/javacpp/

That said, for quick and dirty development, it's a lot easier to just use it on the command line. Coming up with your own custom build tools like you're doing is fine, if that motivates you, great, but I wouldn't recommend it.

[nyholku]

On 17. Jan 2022, at 2.37, Samuel Audet ***@***.***> wrote: That said, for quick and dirty development, it's a lot easier to just use it on the command line. Coming up with your own custom build tools like you're doing is fine, if that motivates you, great, but I wouldn't recommend it.

Yes, I'm not recommending it, just sharing what I do. Custom tooling is a bit grand word for a few lines of Java that mimic the command line interface more or less one to one. For me to point is that all the Eclipse debugging is there to be used and starting the build is immediate without any delay and just one click. The other point is that this is for debugging/examining the innards of JavaCPP not for developing new bindings with JavaCPP. And since it took me more than 15 minutes to find out how to do that I felt it would be worth sharing so as to potentially save that time for someone else. cheers Kusti