Hi :)
On 4/21/20 1:11 PM, Quelrond wrote:
Hi,
Thanks a lot for this work, I was searching for EFL Java binding some
time ago :)
Now I would prefer to have Nim bindings, but I'll definitely have a
look on your repo ;)
I suppose, that the jar could be distributed together with binary
(compiled) EFL, so an 'average' java dev does not need to build them,
isn't it?
Yes absolutely. However, at this point you even need to have custom
patches to efl itself. So i don't think that for this release i can
provide a binary and the .jar themselves. But i am definitely looking
forward to doing that in the future :)
Best regards,
Peter
On 21/04/2020 11:31, Marcel Hollerbach wrote:
Hi,
This is a long mail, containing first an announcement and then a
suggestion.
The announcement:
The last two weeks I have been working on a project called jefl, as
the name might suggest it, these are java bindings, fully generated
out of .eo files.
You might now ask why I was choosing Java instead of something else.
Java was chosen because it's a language where we are not having
working bindings at all. I did not want to have any competition with
any existing project, hence I choose a language that is not there
yet. Another reason why I chose java is that we also need (and have)
JNI bindings, this is nice, because bindings for clojure, groovy or
scala can be built on that as well, with very little time invest, as
the more complex part is already done in the jni part.
For anyone who doesn't know what jni is: When writing bindings c <->
java, you need to have some "glue" that is handling the calling of
your native c code out of the java vm context, and the other way
around. This "glue-layer" is called Java Native Interface (JNI).
As of right now, you can build with jefl little applications, as a
example: https://phab.enlightenment.org/F3868538. The whole thing
then looks like
https://www.enlightenment.org/ss/display.php?image=e-5e9eb1fa897593.48620171.jpg.
I have *not* written the bindings for eina to java yet, so if you use
a API call that returns a iterator, list, array, slice, etc. You will
simply get a empty object returned, where you cannot do anything with
it. This of course will not stay like that, my primary focus was just
on the generation of java API for now.
To test this whole thing:
- Configure your EFL to install eo files (meson configure
-Dinstall-eo-files=true)
- You need EFL with the branch devs/bu5hm4n/eo_file_updates
After the 1.24 release this whole branch will be merged to EFL.
- Install "ant" on your system
- Clone, build, and install
https://git.enlightenment.org/devs/bu5hm4n/jefl.git/
- The previous steps will have created "jefl.jar" in ./build/java
which now can be included in your IDE of choice, where you can write
your jefl app.
If you just want to have a look at the .java files, I uploaded a
snapshot of the .java files to https://phab.enlightenment.org/F3868537.
I am happy over any comment on the .java files, it has been quite
some time since I wrote java, and I might be a bit outdated to "how"
you do things these days, so any comment there is welcome :)
And now the suggestion:
Jefl is meant to be built out of the EFL tree (but maybe in a single
repository), and I think we should do that for more (if not all)
bindings, which are not required in EFL itself (like lua, for bob).
Reasons for this:
- Efl uses meson which is nice for c, however, integrating different
languages with it *into* EFL is highly complex, and we have seen for
C# that this is ending up, simply proxying a native buildtool for the
language. Which however just raises the complexity of the EFL build
itself
- Due to how meson is used in EFL for bindings, the set of generated
files does not follow the structure which is recommended / required
for the language the bindings are generated for. As an example: a
class named "efl.gfx.Entity" in java must be placed in the directory
efl/gfx/Entity.java this cannot be realized with the meson stuff we
have in place, as this rule for placement is not the same for every
file we have, *and* it would require scripting to get the right
position, which makes the whole build process *again* more complex.
- .eo files work in a way where we can specify a class and a struct
in a single file, in java for example, a struct is complied into a
class, as well as a class. But every class which is public, do
require its own file. We cannot detect that at configure-time in
meson, hence this would also not work.
- The problem of having these repositories bitrot is different. We
could have somewhere a .eo file, which contains all possible built-in
types, all possible structures and @by_ref calls etc.. Additionally,
each generator should escape all keywords in a language. If we have
that, it should be quite hard to break bindings from EFL itself.
Additionally, to get an overview of *what* broke bindings, we can
have a travis job that is simply pulling in all bindings repositories
and building them (once a day or so).
To give you an overview to how this works in jefl: at configure time,
meson declares the generator, the generator has 3 outputs, a .c file
(the jni stuff), a build.xml (the build manifest for ant), and a
dependency file. The java files themselves are not known to meson at
any time. Additionally, a custom target is defined which simply calls
"ant" after the java files are generated. The files to generate .java
files for, are loaded from the eolian directory on your system. This
way we *never* have to worry about the placement of files in meson at
all, and all this complexity is removed.
So, what do you think about moving the bindings outside of the EFL repo?
Greetings,
bu5hm4n
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
