com.esri.arcgisruntime:arcgis-java - Source and Documentation artifacts

1219
4
Jump to solution
05-31-2021 06:03 PM
DaveWhitla
New Contributor III

Where are the source and javadoc jars for com.esri.arcgisruntime:arcgis-java ?

The former is extremely important for debugging and the latter is how Java developers learn APIs.

0 Kudos
1 Solution

Accepted Solutions
MarkBaird
Esri Regular Contributor

The JavaDoc files are in the same place as the jar files.  So if you are using the latest version of the SDK (version 100.11.0), you can get them from our maven server here:

https://esri.jfrog.io/artifactory/arcgis/com/esri/arcgisruntime/arcgis-java/100.11.0/

MarkBaird_0-1622572393280.png

We don't publish the source code for the jar files.  Even if you cracked it open you are not going to be able to debug very far into the core logic as this is written in C++ and contained in the supplied libraries compiled for the platform you are running on.

  • .so files for linux
  • .dll for Windows
  • .dylib for macOS

The jar you use from us mostly contains JNI interop code.

The reason we write most of our core logic in C++ is that Java isn't the only development platform we support.  We also support .Net, Qt (QML), iOS Swift and Android (Kotlin and Java) developers and compiling from our common C++ codebase we can provide a consistent experience on all platforms.

Does this help?

 

View solution in original post

0 Kudos
4 Replies
MarkBaird
Esri Regular Contributor

The JavaDoc files are in the same place as the jar files.  So if you are using the latest version of the SDK (version 100.11.0), you can get them from our maven server here:

https://esri.jfrog.io/artifactory/arcgis/com/esri/arcgisruntime/arcgis-java/100.11.0/

MarkBaird_0-1622572393280.png

We don't publish the source code for the jar files.  Even if you cracked it open you are not going to be able to debug very far into the core logic as this is written in C++ and contained in the supplied libraries compiled for the platform you are running on.

  • .so files for linux
  • .dll for Windows
  • .dylib for macOS

The jar you use from us mostly contains JNI interop code.

The reason we write most of our core logic in C++ is that Java isn't the only development platform we support.  We also support .Net, Qt (QML), iOS Swift and Android (Kotlin and Java) developers and compiling from our common C++ codebase we can provide a consistent experience on all platforms.

Does this help?

 

0 Kudos
DaveWhitla
New Contributor III

Yes thanks Mark.

The javadoc jar may not have been indexed - maven still doesn't pick it up when I ask it to fetch source and docs.

I understand both the existence of the native libraries and the rationale for them, and the fact that they "mostly" wrap JNI calls. I actually repackage your "native" zip archives to allow a deployment more consistent with our norms.

But even these sources aid in debugging. They also typically contain comments which you can see right next to the code you are calling, answering such questions as "what does that double argument with an uninformative name represent?" without the developer having to waste time searching a website.

0 Kudos
DaveWhitla
New Contributor III

Actually - ignore the index remark - the proxy config mapping your repo was in error.

0 Kudos
MarkBaird
Esri Regular Contributor

If you ever find there are deficiencies in the JavaDoc we supply with the API, let me know.  We aim to have nicely documented JavaDoc which will help our developer community, but I've no doubt there are imperfections which could be improved.

0 Kudos