[gecode-users] Some Feedback on GecodeJ

[Mikael Zayenz Lagerkvist]

On Mon, Sep 15, 2008 at 2:00 PM, andrew cooke <andrew at acooke.org> wrote:
> except to correct a few errors and mention how disappointed I am to hear that
> GecodeJ is not intended to be used except for teaching.

If I wanted to use Gecode in a Java-project, I would definitely write
the model in C++ and write a small custom JNI-method to interface it.
My main reason (apart from the fact that I think models in C++ are
more readable) is that JNI-calls are fairly expensive, and a
full-blown wrapper like Gecode/J uses a lot of them.


> - I mentioned making Javadoc myself, but it still has the doxygen markup.
> The same markup appears in IDE context-sensitive help.

Well, we try to remove as much of the markup as possible. If there are
more things you'd like removed, please see misc/doxygen2javadoc.perl
for more changes. I know that the math-parts is left in a LaTeX-style,
but I think it is still readable.


> - Iterable, not Iterator.  They are different things.

Yes, I know that. DFSIterator implements both Iterator and Iterable,
as is stated on
http://www.gecode.org/gecodej/javadoc/org/gecode/DFSIterator.html


> - The static methods defined in Gecode seem to be be, in the main,
> convenience functions - shorthand.  Defining a subclass of Space with
> extra convenience methods is not a statement that they "belong" there in
> any engineering sense; it's just putting stuff to hand in the place where
> people expect to find it (for example, via auto-complete).  As with the
> Javadoc issue you are making things harder for users for no particular
> reason.

I'm under the impression that that is a bad design-choice, since it
unduly couples components. If you think otherwise, then you would have
liked Gecode/J before the change: Space inherited from Gecode, which
inherited from JavaSpace, the Java counter-part of the C++ class
Space. We felt the connections were too tangled to be easily managed.

I'm not sure why auto-complete would not find a static import, but
maybe that is because the feature is too new for the IDEs to keep up.


> - I'm afraid I don't understand your argument "The copy constructors
> cannot be made generic, since the variables that need to be updated in a
> Space subclass must be updated there."  Surely a generic method can call a
> constructor itself (and since generics are implemented by erasure it is
> hard to see how introducing them makes anything impossible).  The point is
> not that a constructor is not needed, but that the interface convey the
> requirements to the user.

Due to the way that Gecode and the Gecode/J wrapper works, the call to
update the variables from the class to be copied to the new class must
be in the constructor of the class (e.g., the line "q = new
VarArray<IntVar>(this, share, queens.q);" from Queens.java).

If you know of a way to require a subclass to define a constructor
with a particular signature, then I would be very glad to learn it. As
is, the copy-method in Space checks for the constructor, and raises a
runtime error if it is not present in the class.


> You're free to ignore my suggestions, so I won't argue with you,
<snip/> and
> Given those, I do wonder if you spent much time considering my comments,
> or simply dismissed them out of hand.

I'm not ignoring your suggestions, please don't imply that. I was
merely trying to give a few answers.


> Some extra points since I have used this a little more:
>
> - The constructors for VarArray appear to use generics incorrectly; the
> class type of the contents should use the generic variable defined in the
> opening class statement.

The contents are of the class-type specified in the opening class
statement. If you are referring to the class-objects that are passed
to the various constructors, this is because, AFAIK, the class-object
is needed to construct new elements. This is an unfortunate
side-effect of using type-erasure for implementing generics.


> - Upper bounds on integer ranges are inclusive.  Even in C++ this is odd
> (see Koenig's C++ Traps), requiring "-1" in a lot of code.  Software
> almost always uses "[)" ("half open ranges"), not "[]".

In the context of modeling, I would say that inclusive ranges are more
useful. I don't have any data to back this up though, just my personal
experience.


Cheers,
Mikael

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