[gecode-users] Some Feedback on GecodeJ

[Mikael Zayenz Lagerkvist]

Hi,

Before I answer some of your comments, I would like to give some
background on Gecode/J. Gecode/J is a very close mapping of the Gecode
system into Java; it is not a pure modelling layer like some other
Gecode interfaces (for example Gecode/R,
http://gecoder.rubyforge.org/, by Andreas Launila). We made a
deliberate decision to try and keep the concepts in Gecode and
Gecode/J very close. A benefit of this close mapping is that it is
possible to write simple propagators and branchings in Java directly.
A drawback is that using Gecode/J incurs quite some overhead compared
to plain Gecode.

There are several reasons we did the Java interface to Gecode. First
of all, we needed it for teaching. One of the most important tools
when teaching constraint programming is the graphical search engine
Gist. In the beginning (back in 2005), we did not want to venture into
making a platform-independent GUI in C++, so Java was a better choice.
Since the re-licensing of Qt, Guido Tack has rewritten Gist in C++
using Qt, which gives us a nice and efficient GUI in C++ without the
need to go via Java. Secondly, one of the claims of Gecode is that it
is easily interfacable. We had to investigate this ourselves before
making that claim.

Our current use of Gecode/J is purely in a teaching context. As such,
the basic introduction to the concepts of constraint programming is
given in class, while the on-line documentation is used as a
reference. We are, however, aware that the lack of entry-level
documentation for Gecode can be a problem, and are looking to improve
it (see http://article.gmane.org/gmane.comp.lib.gecode.user/1693).
Please note that this will be for Gecode, not for Gecode/J.

On Sun, Sep 14, 2008 at 6:27 PM, andrew cooke <andrew at acooke.org> wrote:
> First, doxygen is cool, but Javadoc is the standard.  The first thing I
> (or any other engineer) does when assessing a package is look at the
> JavaDocs.

Please see the documentation pages for Gecode/J
(http://www.gecode.org/gecodej/documentation.html). If you want to
generate it yourself, just use make javadoc.


> - Static import functions scare the cattle.  Sure, you want FP in Java and
> using static imports are like functions (woot).  But Java isn't FP and
> you're going to confuse old folks (you threw me).  Especially when the
> majority of the calls (I'm talking about calling Gecode.* methods from
> within a Space) take a first argument of "this" (have you made a wrong
> term somewhere and ended up in Python land?!).  Why aren't these methods
> in some subclass of Space?

The constraint methods are not in a superclass of Space since they do
not belong there -- a Space does not know anything of the various
constraints that can be posted in it, and should not either (the
principle of low coupling in pattern-speak). An important point in
Gecode is to not differentiate between what we as Gecode developers
can do, and what a user can do. If the constraint methods were locked
in the inheritance hierarchy of a Space, then they would look
inherently different from what a user could do.

The fact that the constraint methods all take a Space as the first
argument is due to the fact that you want to tell the constraint where
it is supposed to live.

There is another reason that we decided to have the constraint methods
as static imports: readability. The largest part of a Gecode/J model
is usually the set of constraints that are posted. While Java has some
inherent problems in this area (no operator overloading), at least the
symbolic constraints look fairly clean. Compare with Choco 2
(http://www.emn.fr/x-info/choco-solver/doku.php), a pure Java
CP-system, that uses static imports also for the modeling part. I've
seen libraries where modelling is done by directly constructing
objects for the constraints. These kinds of models are usually not
very readable.


> - You provide Iterator<> access to search results (neat), but I can't see
> an Iterable<> (I may have missed this).  In general, prefer Iterable<> to
> Iterator<> where possible (despite the extra work on your part) because it
> fits in better with the "for ( : )" syntax:
>  for (Foo foo: foos) { ...foo... }
> rather than
>  while (foos.hasNext()) { ...foos.next()... }

See http://www.gecode.org/gecodej/javadoc/org/gecode/DFSIterator.html.
We use the new for-loops ourselves.


> - There seems to be something a bit odd with requiring a copy constructor
> in subclasses of Space.  Couldn't you make the type be something like
> Space<C extends Space<C>> and then have an abstract method that returns C?
>  (called clone or copy or whatever you haven't already used).  Having a
> (poorly documented - by defn, since there are no Javadocs...) constructor
> convention that uses ideas from C++ ("copy constructor" is not a Java
> idiom) isn't a great idea.

As for any type of complex class that needs to be copied, the author
of that class must ultimately decide what needs to be copied.

The copy constructors cannot be made generic, since the variables that
need to be updated in a Space subclass must be updated there.
Originally, one had to implement a copy-constructor and a copy-method
(Space.copy(Boolean share), as is needed in C++), but we eliminated
the copy-method in Java and replaced it with a generic copy-method
that uses reflection.


> I guess this looks like one big moan, but this is a really useful piece of
> software and I am only trying to suggest things that might help make it
> more popular...

I'm not sure what your intended use of Gecode(/J) is, but if you want
to model something complex or something that is very to solve, I would
encourage you to try out Gecode in C++ also. The modeling support is
much better, as is the efficiency.

Cheers,
Mikael

-- 
Mikael Zayenz Lagerkvist, http://www.ict.kth.se/~zayenz/