On Tue, 21 Apr 2020 11:31:11 +0200 Marcel Hollerbach <m...@bu5hm4n.de> said:
> 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. java? my nemesis! my adversary... the dr. evil of languages! :) > 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. the code generator could generate the dummy output meson expects as well as the java standard path. > - .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? bit.rot. there is far more than just having th types and use cases still work. experience tells me that all the enthusiasm for splitting apart... it will bitrot. it'll make it harder to get packaged and distributed. it'll make it harder for people to find and build themselves. experience tells me "no" to splitting. unless of course it's a sly way of getting rid of functional and actually used bindings by not actually saying you're getting rid of them but spinning it a positive as a split then watching it die off then being able to not look bad for having killed them... :) i have been down the path of split and merge and split and merge over the decades. multiple times. splitting creates problems. there needs to be an overwhelming need to split to justify it. in this case there isn't imho. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
