Alternative wrapping with Jpype


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):

pip install Jpype1

pip install -i orekit-jpype==12.0.2.dev2  

and for the orekit-data, thanks @yzokras !

pip install git+

This should be doable without conda and for a range of architectures.

The API is close to orekit (JCC) version and even closer to the Java API than the main python version.
Examples: examples · master · Petrus Hyvönen / orekit_jpype · GitLab

Let me know what you think,

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

1 Like

Hi Petrus,

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.


Hi Romain,

Yes please have a look and let me know what you think…

Jpype handles multiple signatures in similar ways as the recent JCC orekit, with use of match or similar - JPype User Guide — JPype 1.5.1_dev0 documentation

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.

Hi Petrus,

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.

And jpype’s codebase is healthier than jcc’s IMO.

1 Like

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 :slight_smile: