Bringing an interface based java lib to dotty. Ideas?

I am working with Java reasoning library (OWL-API) built on an architectural style from the 90s: a large number of interfaces and the visitor pattern. Many objects created seem in large part not to have equals or hash implemented. And of course they don’t have case classes.

Implementing the Visitor pattern looks to be very tedious as one can see by looking at the OWLLogicalAxiomVisitor for example.

The library is the result of a decades of work on logic and complexity coming from Academia in the field of Description Logics, then standardised at W3C from 2000 onwards. So re-implementing this library is not an option to be considered lightly. To get an idea of the task involved in rewriting: the OWLOntologyManager when pointed at the Financial Industry Business Objects (FIBO) standard, downloads 130 documents that make up about 100 thousand statements, that are transformed into innumerable Axiom objects (eg OWLSubClassOfAxiom).Instead some way of wrapping the many objects created by the framework could be a way to go to make life easier for a scala dev. I could just wrap them somehow in case classes that implement the same interfaces to get the equals, hash and constructors for free, but this is going to end up leading to a lot of tedious code…

Is this the place to use Dotty Macros? Or is there some other feature that could come in useful? I just thought I’d fish for some ideas. There is so much new in Dotty it is easy to miss some easy answer.

In the mean time I’ll get to see how the library works by implementing things the traditional way by extending interfaces. Perhaps doing that will give me some ideas…


I created a Scala wrapper for OWL API called Scowl:

It mainly implements two Scala-based DSLs for composing OWL axioms (a Functional-style and a Manchester-style). Also, there are extractors for using the Functional style DSL in pattern matching.

I’m not sure if it will cover all your use cases, but I find it quite useful. It doesn’t really have scaladoc, but there are example files which show how to code all the axioms from the OWL 2 Primer.

1 Like

Very nice @balhoff. I see that you just do very light weight wrapping on the underlying objects. The extractor pattern is nice and simple to allow one to work with case classes as I see in ObjectExpressions.scala.

It does make the code look a lot more concise and approachable than working with Java library.

Perhaps that will do the job. I am just starting to work on this. My guess is that pattern matching can replace the Visitor pattern they are using. And indeed one can compare

Do these two really do the same thing? If so you should highlight that on your front page :slight_smile:

Do these two really do the same thing? If so you should highlight that on your front page

I think so, unless I have missed something. You’re right, it is a good example of the more concise approach. Sadly the wrapping approach doesn’t give us exhaustivity checking for pattern matching. I wonder if there is a way to fix that while keeping the wrapping lightweight.

Please feel free to file issues on GitHub if you think of improvements that would be useful.