Java
From OpenCog
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)
- Some code (
- 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