publish new version?

[Locke]

With version 2.6.4 and OpenJDK 11 I cannot create / run the reasoner due to java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter.

I saw that you developed support for recent Java versions back in March and have been using a locally build SNAPSHOT version happily since for my development.

I think it is time to create version 2.6.5 so that there is a published version that can be used with Java 11. Or is there any blocker / regression where you might need assistance?

In particular, I want to avoid having a SNAPSHOT dependency in own application, esp. since I'm in the process of finishing up a major release of it and other developers are about to join its development.

[Galigator]

This is true a new version is require.
There is no special blocker/regression, I don't have publish a new version just because I don't have fix any major issue; I spend so mush time on #35 , there is no way to fix it without creating problems elsewhere.

And now my priorities have changes.

[Locke]

Thank you very much for taking the time for doing the release on such short notice!

I just tried it out with my project on both Windows 10 and Debian 10 with each OpenJDK 11 and had no problems.

I spend some time as well looking into this codebase and agree that a major rewrite is required, all the abox branching with a moving branch index makes it hard to follow and in my opinion impossible to support multithreading.

Anyway, my ontology changed a lot since I reported my other issues which improved the performance of my application a lot. Also none of my reported issues affect me (either workaround available or simply not affecting any of my usecases) and from my point of view you don't have to spend much time on them.

Thank you very much again for supporting this project.

[Galigator]

Multithreading support face two problems related to back-jumping (The algorithm use to check the dependency between constraints). First, the implementation use a globally managed array for branchs explored/to be explore, and only a index-number to this array to reference the branch to be explored. Second back-jumping by it-self a non-multithread algorithm; Recent research (2011) show evolution of this algorithm into a multithread version; but the paper is require a serious background in CSP algorithms and a lot more time than I have to transfers it to openllet.

If your ontology don't have any 'negative' constraint that would for a backtrack/backjump some where then multi-threading should work. For this purpose there is an option that enable multithreading in the ABox, this allow check of consistency in a multi-thread stream. But having an ontology without 'negative' constraint is rare.

A solution less costly to develop may be : propagate type-safe interface everywhere in the source, add interface on every class, make things immutable as possible, and instantiate as many reasoner as threads while taking profit of memory sharing.