API doc availability

I just noticed that the library JavaCPP has been updated (1.5) while IJ-OpenCV uses 1.4.2.

The problem is that the documentation for 1.4.2 does not seem to be available anymore, I could find it at this link but for how long… :sweat_smile:

There was some kind of duplication in 1.4.2 between classes in org.bytedeco.javacpp and org.bytedeco.opencv, which were not taking exactly the same type of object as argument.

It seems that the org.bytedeco.javacpp was removed in 1.5 while it’s precisely the one that IJ-OpenCV is using.

Is there a way to archive the documentation ? or tips to access documentation of passed versions ?
The best would be to update IJ-OpenCV to use the last JavaCPP version in the long term but it would spare so effort currently.

No need to archive, the javadoc of each released version is available in the *-javadoc.jar artifact on the Maven repository, e.g.:


That artifact will be used when you browse the javadoc of your dependencies via an IDE (such as Eclipse).

For a browsable version, you can have a look at:


We can also discuss about hosting a version of the javadoc on javadoc.scijava.org if you think it’s useful.

How about upgrading the dependency to 1.5? Would it require a lot of changes in IJ-OpenCV?

Thanks for the resource !
However, I realized that what is needed is the previous version of the javadoc for JavaCPP-presets and not directly javacpp…
Unfortunalty it is not available via javadoc.io neither via Maven :sweat_smile:

I think it would be mostly changing import statements to the equivalent classes in org.bytedeco.opencv which should not be a big deal.
The 1.5 API has the advantage to be cleaner as all the duplicated methods (with the domain org.bytedeco.javacpp) have been removed, which could be misleading in the previous version.

In Fiji, it would break code relying on the 1.4.2 version obviously, but having the current update site with version 1.4.2 renamed/tagged as deprecated and having a separate update site with the new version could be an option right?

We should probably consult the people in charge of JavaCPP, but it could be a good idea indeed.