Wayland McWayface tutorial project done, feedback on jextract

Mark Hammons mark.hammons at inaf.cnrs-gif.fr
Mon Mar 4 08:49:57 UTC 2019


Hi all,

I finished all three parts of the wayland mcwayface tutorial and the 
resulting code is here: 
https://github.com/markehammons/Wayland-McWayface_JVM-edition

Something I had trouble with in the second part was mixing libraries 
with jextract. I needed something from stdlib.h to complete the second 
part, but that didn't belong in the wlroots package. Further, I was a 
bit afraid that if I used jextract for it I'd get a jar that had 
classfiles that conflicted with wlroots.jar (though that seems unlikely 
with something as basic as stdlib.h). So I guess my first question is, 
is there plans to make jextract make dependent bindings? For example, in 
this project I just went and bound wlroots and let jextract create 
bindings for all dependencies needed to make those bindings work. But 
what if I wanted to have a wayland jar with the wayland bindings? It'd 
be nice to give jextract that jar when binding wlroots, have wlroots 
find out that the wayland jar contains bindings for some of the stuff it 
needs and create a wlroots.jar that needs wayland.jar on the classpath 
to worth rather than having wlroots.jar and wayland.jar be potentially 
conflicting (I know they wouldn't conflict on the wayland classes cause 
those would be in a package like wayland rather than 
usr.include.wayland, but they'd probably conflict on the shared 
dependencies between the two).

A second idea someone mentioned when I posted my results on reddit was 
making multiplatform bindings with jextract. I believe this is at least 
somewhat related to my first suggestion above. I would think creating a 
multiplatform binding to opengl would be doable with jextract. Just 
create an opengl-windows.jar on windows, an opengl-mac.jar on mac, and 
an opengl-linux.jar on linux. However, I'd think you'd need to load the 
right one at runtime thanks to them being conflicting, in which case an 
interface jar that could be used at compile time would be helpful. 
Basically, jextract would generate two jars, an interface and an 
implementation. Then the linux, windows, and mac jars would be the 
implementation and you could load them in at runtime to implement your 
interface. Does that work?

Thoughts?

In any case, I'll probably start working on scala tooling and making the 
code I've written more scala friendly at this point. I've intentionally 
left it looking very C like to make direct comparison between it and the 
original tutorial project easier. After I've changed the code to be more 
like idiomatic scala I'll probably start trying to port the sway wm 
(https://github.com/swaywm/sway) to the jvm, starting with pulling 
features from sway into this project to make it a more full featured wm.

Thanks,

Mark



More information about the panama-dev mailing list