Replies: 2 comments
-
As someone who would rather write x86 assembly then do anything with javascript, this sounds like a good idea to me. While it does initially sound like it would be out of scope, if it helps use a widely used Java library from Python, and is completely optional, then I'd say it is within scope. I'm sure there are plenty of user that would be happy with this. I say this and yet I wouldn't touch any web development with a 40ft pole. |
Beta Was this translation helpful? Give feedback.
-
I made some progress on this at work and was able to get a full language binding to javascript through jpype. However, there are some caveats that may not be good for general use.
I was able to make a fully interactive shell under python calling the majority of Javascript operations. So things like async and await are still a work in progress but look doable. Is this valuable to anyone? I was able to get a full web page up, add event handlers from python, get them serviced, and interact witb it naturally as if it was fully in python. So it is functional. |
Beta Was this translation helpful? Give feedback.
-
Thus far jpype has limited itself to providing the minimalist access to Java. Other than implementation of extends we are almost complete. This in theory would provide access to any language written in the jvm.
However, recently I came across the javafx implementation of web view in which Javascript is available to Java and one can collect Java code to Javascript. Rather than being directly in Java, it was provided to Java with its own reflection system. We can use that narrow bridge to connect not from one city to the next (Python to Java) but to the larger webkit area (Javascript, webassembly, websockets, etc). We just need to add the basic plumbing and we can have a much wider universe.
I propose that we use that bridge to provide access to webkit for Python allowing Python to access Javascript and having Javascript call Python. It would take the form of some customizers and properties added to the javafx webengine class. We would implement some support functions in a jar shipped with jpype (possibly different from org.jpype to avoid dependencies) and a module jpype.javascript. because Javascript is basically untyped our customizers would need to reach through and access the Javascript dictionaries and present them to Python on the fly. Most of the exchange would be through JSON. We would direct Javascript calls to Java where we can use a function converter to install pure Python callbacks. A trap layer would need to capture exceptions to reflect them back to the correct location.
I believe the total code for this is minimal as we already have a rich capability to create on the fly customizers. It is just the dict to dict hookups that would need some extra logic in the C layer. It would have to be dependency free as we don't want to be shipping JavaFX nor forcing a huge number of customizers on users that don't need them.
Does anyone have any thoughts about this possibility? Does it seem within the scope of the JPype project?
Beta Was this translation helpful? Give feedback.
All reactions