WIP: Java bindings

[adjabaev]

Objective

Make taffy usable in Java programs

Feedback wanted

Feel free to give me advice over what I am doing as it is the first time I am actually writing Rust/ jni bindings

TODO

• Implement style in taffy_tree
• Implement children in taffy_tree (basically returning a list)
• Figure out whether dirty and mark_dirty might be useful to Java users
• Implement NodeContext related stuff
• Find a way to implement compute_layout_with_measure, (do I write a Java wrapper around MeasureFunction?)

[adjabaev]

Do you think it is a good idea keeping Taffy in name of every class (I am asking the question because I feel like java doesn't have as much concise ways to express certain ideas which leads to some code looking quite long) (not even talking about the fact that in Java the types of variables are usually explicitly written).
Also I'd be very curious knowing what do you think so far

[nicoburns]

@adjabaev very excited to see this. I'm on vacation (with limited access to computers / internet) atm. But I will definitely review this when I get back.

One thing that I have noticed from writing C and WASM Bindings (neither finished/merged yet), and that I also see here, is that there is a lot of repetitive code related to defining enums, converting enums, fields on Style, methods on TaffyTree, etc that is duplicated in each binding and in the main Rust implementation. And I have been thinking it might be good from a maintenance perspective to use code generation to automatically generate this code from a metadata definition similar to Yoga's enums.py script (this would be pretty helpful when we add new style fields for example).

Regarding naming conventions, I'm not sure. Just Java have namespaces? C doesn't, which is the main reason why it has everything prefixed.

[adjabaev]

@adjabaev very excited to see this. I'm on vacation (with limited access to computers / internet) atm. But I will definitely review this when I get back.

Glad you like the initiative! :)
I hope you will enjoy the rest of your well deserved vacations (I actually think so, it is crazy the amount of things that have changed since the last time I have seen it!)

One thing that I have noticed from writing C and WASM Bindings (neither finished/merged yet), and that I also see here, is that there is a lot of repetitive code related to defining enums, converting enums, fields on Style, methods on TaffyTree, etc that is duplicated in each binding and in the main Rust implementation. And I have been thinking it might be good from a maintenance perspective to use code generation to automatically generate this code from a metadata definition similar to Yoga's enums.py script (this would be pretty helpful when we add new style fields for example).

It is definitely something I have noticed and I would be more than glad to find a way to automate this stuff, for enum related stuff, I feel like its not gonna be very difficult (thanks to Java's Enum.ordinal(). But in the same time I am wondering if we couln't just Serialise/ Deserialise stuff as Json strings. At least I feel like it would lower the implied work by a lot, however I cannot tell what it is going to be performance wise.

Regarding naming conventions, I'm not sure. Just Java have namespaces? C doesn't, which is the main reason why it has everything prefixed.

Yes, Java (and Kotlin) have packages which are basically namespaces, so I removed Taffy from every class (every file still start with "package com.dioxuslabs.taffy;" (except for TaffyTree because it is its original name)

[adjabaev]

Hi :)
I did some changes to how enums work, these are now generated automatically. This is probably something that could go into a meta PR that would help all bindings, but I thought it would be nice to showcase the idea here before flooding with another PR. What do you guys think?

Also for now, it only generates classic enums without any parameter because in Java there is not such notion as enums that have different parameters (signatures)

---

Also another question, the MeasureFunction/ NodeContext stuff seems very hard to translate to Java dynamically as NodeContext can by anything, if anyone has an idea, i'm all ears! :)

[nicoburns]

I think this file could be auto-generated too. My suggested strategy would be:

1. Create a trait:

trait FromJavaEnum {
     const JAVA_CLASS : &'static str;
     fn from_ordinal(ordinal: i32) -> Option<RustType>;
}

2. Auto-generate an impl of this trait for each rust enum when generating the java enum.

3. This file should then just need two (generic) functions: one for T (that returns default if the value is null) and one for Option

[adjabaev]

This was actually an incredible idea, just commited an implem of this, would be very interested in knowing what you do think about it :)

Also i did a little refactor, so we can split different steps (enum generation/ transformers) and different languages (just java.rs 's for now, but we can imaging variants for js, c, cpp, etc)

[nicoburns]

You could consider "flattening" the fields that use Rect, Size, and Line (so have width and height fields instead of size). I reckon that would simplify the API quite a bit (and mean you wouldn't need to define the geom java types or conversions at all.

[adjabaev]

I guess I could look at it, but what about situations where only a part of components of a geom is defined? (let's say only left is defined in a Rect)

[nicoburns]

I guess if you flatten Style you'll probably also want to flatten Layout.

[adjabaev]

Also clippy doesn't validate but it looks like it isn't due to my code (and it wasn't the case before i wrote it, I tried looking for the reasons but i do not manage to understand it and would like to avoid modifying Taffy code if it isn't necessary)