-
Notifications
You must be signed in to change notification settings - Fork 315
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider raising Java version requirement to 17 or 21 to allow for algebraic data types #1101
Comments
@julesjacobsen Indeed, version 6 will require Java 17. I've not started work on it yet, but that's the last important change before a release candidate for it. |
Glad to hear this is on the cards. It's unfortunate that pattern matching for switch isn't final in 17, but I'm guessing you'll be targeting a post-17 LTS (Java 21?) for owlapi version 7 where this could all come together? |
That's more or less the plan, unless the version 6 release candidate ends up coming out when V21 becomes available. |
I can't actually get OWLAPI working with Java 17:
|
@udp Version 5.1.0 was still using Guice, that's not been the case for quite a while. I've not tried running version 5.1.0 with Java newer than 8. Version 5.5.0 is built with Java 11, including tests that exercise this code path. Some of the most recent 5.1.x versions should work as well. |
Hi, I know this is probably a long shot given the downstream dependencies but as you're probably aware Java 17 has been released for at least a year now and is the latest LTS release (soon to be superseded by 21). However, the benefits it brings to the OWLAPI are sealed classes and pattern matching for switch which allows some much cleaner code both internally and for consumers.
Maybe for owlapi version 6 or 7?
For example the
OWLAnnotationValue
would benefit from beingsealed
would become
Where did the visitor pattern
accept
methods go? This isn't needed with sealed classes and pattern matching for switch. See NipaFX's nice explanation. Also no need to read the comments about what interfaces are permitted.Similarly the
OWLAnnotationSubject
becomes sealed and permits IRI and OWLAnonymousIndividual
and so would
OWLAnnotationAxiom
(wouldpermits OWLAnnotationAssertionAxiom, OWLAnnotationPropertyDomainAxiom, OWLAnnotationPropertyRangeAxiom , OWLSubAnnotationPropertyOfAxiom
)which would allow current code like this (taken from obographs):
to become a lot less noisy and more succinct:
The text was updated successfully, but these errors were encountered: