Java

opencog-java is an experimental attempt at embedding OpenCog framework & libraries (including Scheme & Cython bindings) inside a Java8 (web)app. --Hendy (talk) 04:12, 13 July 2014 (CDT)

Initially by User:Hendy to explore the feasibility of running OpenCog in Java, particularly with regard to:

• Performance: Since this is the primary (possibly the only) potential benefit of C++... Is it possible to have comparable (or better) performance than C++ code, while retaining convenience of Java?
• Cross-platform: Single usage guide, minimal differences between Linux/Windows/OS X steps, Docker/VirtualBox/Vagrant not required.
• Ease of development: Clone, (optionally import to IDE), build, run
• Rapid development: Change code at runtime without restarting server.
• Ease of testing: Benefit from mvn test, Eclipse JUnit integration. And potentially FitNesse, JBehave when appropriate.
• Exploratory/visual approaches: Augment Atomspace Visualization with editing features, probably embedded shell implemented in AngularJS (client) and REST API endpoint
• Hypermedia RESTful API, both easier to use and easier to develop: Make REST API easier to use with Swagger, and easy to develop with Spring Hypermedia HATEOAS
• Ease of deployment: Package as single tar.bz2. Extract, run.
• Parallelization: Use multiple processors effortlessly and efficiently.
• Distributed data and compute grid: Use multiple nodes effortlessly and efficiently.
• Independency to a packaging tool: e.g. Docker, Debian/Ubuntu package

Initially, the structure will be quite "strange", i.e.

Java embeds
    OpenCog C++, which in turn embeds
        Scheme bindings, and
        Python bindings

As for bindings:

• For Scheme bindings, it may be possible in the future to retrofit some parts to Clojure, to achieve native code interoperability without bindings
  • May also consider Webchurch to augment or replace Clojure (see below)
• For Python bindings, it may be possible in the future to retrofit some parts to Jython, Scala, Groovy, or JavaScript to achieve native code interoperability without bindings
  • Using JavaScript has the benefit that some code is potentially runnable in a web browser (which works on mobile devices as well), or NodeJS interpreter
  • C++ can also embed JavaScript the same way it binds with Scheme or Python. However, JavaScript on JVM is much more integrated and easy to use
  • Webchurch is a Church probabilistic programming language interpreter implemented in JavaScript and runs in a web browser

Rationale:

• OpenCog Python (Cython) bindings requires (infrastructural/technical) maintenance effort, which potentially could be reduced by using a JVM language; which effort could then be channeled to improve OpenCog AI features
• C++ code is naturally more verbose than Java
  • Some code (#ifdef, etc.) is purely for cross-platform purpose, which is not required in Java
  • Parts of OpenCog code do not gain the advantage of C++ (i.e. not performance-sensitive)
• Java can use C/C++ libraries quite easily through JNA/JNI/BridJ. The reverse is much harder.
• Java can easily use many libraries directly, especially the ones published in Maven central, and Apache Foundation libraries like Apache Tika, Mahout, Jena, etc.
• Some OpenCog code deals with cross-platform issues, so the current approach is to use VirtualBox or Docker or vagrant. Using Java reduces cross-platform issues which lowers the barrier of entry.
• Some OpenCog code deals with dependency/deployment/packaging tasks, this could be reduced by using Maven. Less steps mean lower the barrier of entry.
• Modularization of OpenCog Java parent project allow OpenCog subprojects to be developed, launched, and tested independently; which is easier and faster in the case other subprojects require additional dependencies and setup. Again, lowers barrier of entry.
• For packaging, C/C++ library binaries for each target platform (Linux32/Linux64/OS X/Windows) can be embedded inside JARs, therefore simplifying distribution and end-user usage.
• Since HypergraphDB runs in Java (and I hope it does so for the foreseeable future --Hendy (talk) 05:02, 14 July 2014 (CDT)) using HypergraphDB as AtomSpace database is cheap and easy, with potential for deeper integration. See also Distributed AtomSpace Architecture Redux