I have been experimenting for a while with an alternative python wrapping based on the library Jpype (in contrast with the nominal one using JCC). This Jpype version is not fully as capable in terms of missing subclassing of Java classes, but does have support for implementation of interfaces so most things are still doable. It is much lighter in maintenance and operations as it does the analysis of jvm classes on the fly, and do not suffer from the casting problem that JCC has. It also has better stub-support for type hints.
If you would like to try out, I have also created a pip package (as this is architecture agnostic):
EDIT: Changed to dev2… and separate Jpype installation as otw it is fetched from the test site which will not be the case if orekit_jpype is fully released
Thanks so much for this test version. I will try it out as soon as I get what feels like a good enough chunck of time for it.
A few questions already:
how does Jpype do with methods that have the same name but different signatures, which is not a thing in Python? Edit: FYI, I did use match with Python 3.11 and the recent update, but I’m worried about performance
do you think this library is likely to be more or less maintained than JCC? I’m looking at the long-term future of the wrapper here.
Question two is hard to tell, it is definitely much easier to make a release and change version etc as the jars are directly from orekit and basically no wrapper code is needed, all is done by the jpype library.
As of now i see it as complimentary, JCC is very capable and well proven, but for educational, test, or just doing something simple, this Jpype wrapping is very smooth. Over time we may see how this developes, but too early yet.
This is awesome, thanks a lot!! It looks good and the ease of installing the wheel with pip (so without the need for conda) is amazing. I will test it more in depth soon.
About the future of jcc vs jpype:
jpype is actively developed by several developers on Github.
jcc is maintained by mostly one developer as a subfolder of the pylucene project in a SVN of the Apache Foundation. jcc’s developer is quite friendly and responsive to bug tickets or improvement ideas (on the Apache JIRA) and jcc receives patches from time to time, but it is far from having an active community of developers.
Yes Jpype had a lot of development some year(s) ago but been around for quite some time and is more accessible indeed.
I think the main drawback of Jpype is that it cannot subclass in python which makes some things in orekit not possible to implement - but it is just the abstract classes, all interfaces are possible to implement which covers alot of the use cases.
I think also one interesting upside of Jpype_orekit is that it is easy to implement own java jar’s and add to the wrapper - a more dynamic development where it is possible to make some time critical stuff in java and still have the notebook use case or what is preferred in python. No recompilatiion is needed.
But I have used it too little to see all quirks, the JCC version we know quite well by now
Hi, an update on this, after @Serrof talk this Friday i got some inspiration to play with this and made an example project of how to incorporate custom java classes into a python project. This would enable to write some time-critical parts as custom java classes while still using the python ecosystem for all the top level stuff. Work in progress, but I think this can be useful.
That sounds very interesting. I really need to find time to look at all this Jpype stuff you’re playing with. Thanks again for all the Python wrapping.
Hi Serror, and thanks for a very interesting talk, sounds like a really complex problem solving
Yes, I think for such use case that you had it could be good to have the possibility to incorporate some custom detectors, handler etc at high performance while still having the convenience of access to the python ecosystem for plotting, scripting etc.
If you find some time to test, don’t hesitate to reach out if you run into issues, it is still a bit early and we’re gaining experience with it.
I’ve used the new wrapper a bit more and it’s neat, thanks alot Petrus and Clément.
I guess the biggest drawback for users is the extension of abstract classes, as I think is known.
On a somewhat similar level, I assume that when one inherits from an interface, the default implementations from Java are lost, is that correct?
Yes jpype is an interesting tool that makes to a large degree a more friendly wrapper. The AbstractClasses is indeed a drawback but for most cases this can be solved with interfaces. Not all.
If you refer to default methods they are indeed supported and optional to implement in an interface. If not the java default method will be used. This is quite new since some moths ago (and coming from a jpype feature).
