Wayland McWayface tutorial project done, feedback on jextract

[Maurizio Cimadamore]

On 04/03/2019 08:49, Mark Hammons wrote:
> 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).

The short answer is yes.

You will basically have two choices: self-contained artifact (which is 
what we do now), which is optimal in terms of minimizing havoc and 
incompatibilities with different libraries. And then a multi-jar mode, 
where a newer extraction can point to a previous extracted artifact.

One thing that we need to avoid pretty badly is to end up with jars with 
same (or, worse, subtly different) copies of the same classes, as that 
will be a pain for clients to deal with.


>
> 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?
I think that's a natural place to land, yes; in general, as you are 
starting to see, there are many requests for jextract to generate format 
XYZ (e.g. .deb ?), and we can't possibly support them all. That's why I 
think a more productive approach would be to start focusing on a public 
API which can be used to customize jextract in several ways, adding 
filters, adding backends to generate new output formats, etc.
>
> 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.

One question, I've seen in your great github landing page that you had 
issues with gnome terminal - is that a Panama issue, or something else?

Maurizio

>
> Thanks,
>
> Mark
>