Obsolete -- this wiki page describes some ideas that were never pursued.
- 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)
- 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