- ant is missing in the build requires

(In reply to comment #1)
> - ant is missing in the build requires

Thanks.  I've added it, and a couple for little tweaks.

Spec Name or Url: http://spindazzle.org/FE/devel/kawa.spec
SRPM Name or Url: http://spindazzle.org/FE/devel/kawa-1.8.beta-2.src.rpm

I am not familiar with techicalities of gcj, so here are a few questions:
There is a kawa.jar and /usr/lib/gcj/kawa/kawa-1.8beta.jar.*
When started using the kawa-script, what is actually used?
Is it so that the .so is used when present, and the jar file otherwise?
Does gji know where to look for the .so file?

Here a few other problems:
- kawa.1.gz seems to be empty
- in /usr/bin/kawa:
  /usr/bin/java is a link to an alternatives file
  Since this link may point to an other java implementation, perhaps
  it would be better to hardcode /usr/lib/jvm/jre-1.4.2-gcj/bin/java
- is it possible to build with --enable-kawa-frontend?
- kawa -w opens a window which obviously uses GTK, however menu font size
  is much smaller than the default on my desktop (it's not very useful
  anyway)

(In reply to comment #3)
> I am not familiar with techicalities of gcj, so here are a few questions:
> There is a kawa.jar and /usr/lib/gcj/kawa/kawa-1.8beta.jar.*
> When started using the kawa-script, what is actually used?
> Is it so that the .so is used when present, and the jar file otherwise?
> Does gji know where to look for the .so file?

Both are used by the gcj java alternative.   gij starts by loading the .jar
file.  Before interpretation, however, it looks up each class' checksum in
/usr/lib/gcj-4.0.1/classmap.db, where it should find matches pointing it at
kawa.jar.so.

When you using a Sun/IBM/BEA alternative it just uses the .jar file.

> Here a few other problems:
> - kawa.1.gz seems to be empty

Hmm... strange.  Not for me.  Maybe this happens if you don't have groff
installed.  I'll add a BuildRequires.

> - in /usr/bin/kawa:
>   /usr/bin/java is a link to an alternatives file
>   Since this link may point to an other java implementation, perhaps
>   it would be better to hardcode /usr/lib/jvm/jre-1.4.2-gcj/bin/java

No, this is how it's supposed to work.  kawa should run on the current java
alternative.

> - is it possible to build with --enable-kawa-frontend?

Yes, I can do this.

> - kawa -w opens a window which obviously uses GTK, however menu font size
>   is much smaller than the default on my desktop (it's not very useful
>   anyway)

This will improve automagically as libgcj improves (hopefully dramatically when
we switch to GCJ 4.1).

"kawa -w" runs perfectly if you switch to the sun java alternative.

Thanks for your feedback!  Here are new bits:

Spec Name or Url: http://spindazzle.org/FE/devel/kawa.spec
SRPM Name or Url: http://spindazzle.org/FE/devel/kawa-1.8.beta-3.src.rpm

- the man page is now installed, but it is preformatted; this is an
  error in the Makefile responsible for installing the man page;
  you should manually install the source man page as %{_mandir}/man1/kawa.1
- with the readline frontend, the start script is replaced by a binary;
  the behaviour is different, because the script uses the env variable
  JAVA for the java runtime, and if it is not set it uses /usr/bin/java;
  the executable on the other hand always uses the first java it finds in
  the path; this is problematic since I have a link to /usr/local/bin/java
  to Sun's JDK; we should have a guaranteed behaviour, I think, whatever
  the individual configuration a user might have
- otherwise everything seems ok

I noticed that you configure without --with-gcj. Is this intentional?
When I compile with --with-gcj, a binary kawa-bin will be produced.

I am quite experienced with traditional java, but the fedora java setup
leaves me a little stunned :-(
Ok, what I found out is that you don't compile with gcj, but use a "simulated"
traditional jdk setup, i.e. compile java byte code with ecj and interpret it
with gij. Is this correct? Then you take the additional step to gcj-compile
the whole .jar and put it in the gcj database.
The other way is to compile the .java files individually and link to a native
binary (this is what --with-gcj) does.
Are both ways equivalent in that a native version is executed, in the one
case an executable in the other case a shared library? Can one prefer
one over the other?

(In reply to comment #5)
> - the man page is now installed, but it is preformatted; this is an
>   error in the Makefile responsible for installing the man page;
>   you should manually install the source man page as %{_mandir}/man1/kawa.1

Fixed.  I'll notify the upstream maintainer (Per Bothner).

> - with the readline frontend, the start script is replaced by a binary;
>   the behaviour is different, because the script uses the env variable
>   JAVA for the java runtime, and if it is not set it uses /usr/bin/java;
>   the executable on the other hand always uses the first java it finds in
>   the path; this is problematic since I have a link to /usr/local/bin/java
>   to Sun's JDK; we should have a guaranteed behaviour, I think, whatever
>   the individual configuration a user might have

Ok, I've built it to use /usr/bin/java, which is controlled by alternatives.

> - otherwise everything seems ok

Thanks.  Here are the updated bits.  This version also builds and installs a
javadoc package.  Comments appreciated!

Spec Name or Url: http://spindazzle.org/FE/devel/kawa.spec
SRPM Name or Url: http://spindazzle.org/FE/devel/kawa-1.8.beta-4.src.rpm

(In reply to comment #6)
> I noticed that you configure without --with-gcj. Is this intentional?
> When I compile with --with-gcj, a binary kawa-bin will be produced.

Yes, I'm intentionally ignoring that option.  It builds kawa with the old ABI. 
We want the new "Binary Compatibility" ABI.  Running "aot-compile" on jar files
is the way to go these days.

(In reply to comment #7)
> I am quite experienced with traditional java, but the fedora java setup
> leaves me a little stunned :-(

Hopefully you'll recognize its genius once you get use to it :-)

> Ok, what I found out is that you don't compile with gcj, but use a "simulated"
> traditional jdk setup, i.e. compile java byte code with ecj and interpret it
> with gij. Is this correct? 

Yes, this is close.  The simulation is provided by java-gcj-compat, whose goal
is to let us build and run random java projects unmodified on our Free Software
stack.

> Then you take the additional step to gcj-compile
> the whole .jar and put it in the gcj database.

Yes.  If you run "gcj-dbtool -l /usr/lib/gcj-4.0.1/classmap.db" you'll see a lot
of lines like:

[1153] c6514c3f8fa5e678faa7555b1fd449 -> /usr/lib/gcj/jython/jython-2.2.jar.so

When the gcj runtime loads bytecode for a class, it computes a cryptographic
signature of that bytecode and looks it up in this database.  In the case above,
when libgcj loads the bytecode corresponding to c6514c3f8fa5e678faa7555b1fd449,
it should look for a natively compiled version of that class
/usr/lib/gcj/jython/jython-2.2.jar.so instead of interpreting the bytecode.

> The other way is to compile the .java files individually and link to a native
> binary (this is what --with-gcj) does.
> Are both ways equivalent in that a native version is executed, in the one
> case an executable in the other case a shared library? Can one prefer
> one over the other?

We prefer the method I described above.  There are lots of reasons to like it:

- It makes building and running java projects much simpler.  Instead of
maintaining wildly patched and unique build systems for these projects, we can
use the upstream build system virtually unchanged (see
http://sources.redhat.com/rhug for more insight).  (btw, kawa is one of the rare
projects that had special gcj build infrastructure)

- Many projects are written to load, link and run bytecode through special
ClassLoaders.  The classmap mechanism lets us still load and run native versions
of these classes.  This was impossible before.

- Java also lets you load, link and run classes by name
(Class.forName("MyClass")).  We had a very fragile system for handling this
before (see Fedora Core 1).  The new mechanism has proven to be extremely robust.

- "Requires: readline" is not necessary, rpmbuild takes care of that
- ldconfig is not necessary

(In reply to comment #11)
> - "Requires: readline" is not necessary, rpmbuild takes care of that
> - ldconfig is not necessary

Oh, right.  Done.

Spec Name or Url: http://spindazzle.org/FE/devel/kawa.spec
SRPM Name or Url: http://spindazzle.org/FE/devel/kawa-1.8.beta-5.src.rpm

Is this OK to import now?

Thanks!

Ok, APPROVED

You can also build for FC4, that's what I tested on.

(In reply to comment #14)
> You can also build for FC4, that's what I tested on.

Thanks, but there's no rush.  While kawa does build nicely, a gcj bug is
preventing it from running properly.  

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23182

This bug was fixed a couple of days ago.  I'm not going to put this in FC4 until
we have a new gcj there.

(In reply to comment #3)

> - in /usr/bin/kawa:
>   /usr/bin/java is a link to an alternatives file
>   Since this link may point to an other java implementation, perhaps
>   it would be better to hardcode /usr/lib/jvm/jre-1.4.2-gcj/bin/java

Actually the system is more fine-grained than this. You can specify 
/usr/lib/jvm/jre-1.4.2 or /usr/lib/jvm/jre-gcj if you only care about a
particular vendor or version