Re: jgir enhancement

[Colin Walters <walters verbum org>]

On Fri, Jul 11, 2014, at 06:55 AM, Farkas Levente wrote:
> hi,
> we're in a process to rewrite gstreamer-java to use
> gobject-introspection and we'd like to use jgir as a base for it.
> but we've got a few questions about the current jgir if you can help us.

A high level note: so I obviously haven't done anything on JGIR in
years.  The reasons for that mainly have to do with the rise of
JavaScript, then I moved on to working on software upgrade systems.

Also since then, the java-gnome people have not been idle - as I
understand it substantial portions of the backend are now using
introspection data instead of .defs files.

However, I had (and still have) a fundamental disagreement with the
java-gnome people in that they want to manually expose and redocument
APIs to tweak them to be more Java-like, whereas with JGIR I was
attempting automated bindings which are better for people who know the
platform.

A simple example of that is I would use GFile as is, rather than
replacing things with the Java File class.

> - first of all jgir use "GLib/GObject interface layer adapted from
> gstreamer-java". our question is why? it seems repository and glib2
> itself already has gobject-introspection ie:
> so why we can't use it fir itself also?

Because GObject and below are special and need custom bindings.

> - currently the src/org/gnome/gir/repository contains the wrapper for
> the git itself. are these hand made classes? since there is a
> GIRepository-2.0.gir (at least in the current gobject-introspection
> version). so wouln't it be better to generate these classes to? or these
> files contains some hacks?

Maybe.  There's been some work on that.  pygobject maintains a custom
Python binding to libgirepository in a similar way.  gjs just does most
things in C.
 
> - as we can see jgir only can create jar file ie only class and not java
> source files. wouldn't it be more clear way to create java file from the
> xml (not the typelib) in this case we can generate docs and java code
> too and simple compile the java codes? 

> From a packaging perspective then you need to rebuild all of the
bindings using a full JDK whenever one of the C libraries changes.  My
original thought was that we could just have a post-install trigger that
regenerated the .class files from the .typelib, whenever they changed.

Maybe that was never realistic though.  The compilation route then you'd
probably end up with some sort of "java-gobject-introspection-classes"
package that would need to rebuilt every time any package containing a
.gir changed, and would contain class files for all packages.  (Or
alternatively, create a -java-gir package per bound package, e.g.
libgstreamer1-java-gir).

> can you give us a bit detailed description of the current code ie some
> kind of description for programmers. of course the main question is just
> those ~10 files in src/org/gnome/gir/compiler who do they work, what is
> the purpose of each what we've to fix, enhance or rewrite etc. 

I can't commit to doing that now, I'm sorry.

> how do
> you generate classes etc. may be we can do some kind of conference call
> after review all the code and we've more technical questions about it.

I hope the above helps.  I might be able to answer further more specific
architectural questions.