Following psudo patch might resolve this problem

--- config_office/set_soenv.in  13 Jan 2006 16:37:16 -0000      1.86
+++ config_office/set_soenv.in  2 Feb 2006 05:13:31 -0000
@@ -68,7 +68,7 @@
 #
 # Help variables.
 my ( $USR, $ETC, $BIN, $LIB, $LIB64, $INC, $INCLUDE, $DEV, $OPT, $LOCAL, $SOLENV, $SOLVER, 
$CONFIG, 
-     $USR_BIN, $USR_LIB, $USR_LOCAL, $USR_CCS, $JAVA_BIN, $JAVA_LIB, $JAVA_INCLUDE,
+     $USR_BIN, $USR_LIB, $USR_LOCAL, $USR_CCS, $JAVA_BIN, $JAVA_LIB, $JAVA_INCLUDE, $JAVACMD, 
      $SOLARENVINC, $USR_DT, $USR_OPENWIN, $TCSH_PATH, $XLIB, $XINC,
      $CYGWIN_PATH, $language, $dict, $ASM_PATH, $ps_STLPORT_LIB, $L_STLPORT_LIB,
      $STLPORT_stlport, $STLPORT_inc_stlport, $PERL_PATH );
@@ -1679,6 +1679,9 @@
    ToFile( "JAVAINTERPRETER", "@JAVAINTERPRETER@","e" );
    ToFile( "JAVACOMPILER",    "@JAVACOMPILER@",  "e" );
    ToFile( "JAVADOC",         "@JAVADOC@",       "e" );
+   ToFile( "JAVACMD",         "@JAVACMD@",       "e" );
 }
 if ( $platform =~ m/darwin/ )
 {  ToFile( "DYLD_LIBRARY_PATH", $LD_LIBRARY_PATH,   "e" );
                                                                                              


@@ -2032,8 +2036,14 @@
 if test "$JDK" = "gcj"; then 
    save_CFLAGS=$CFLAGS
    save_LDFLAGS=$LDFLAGS
+   JAVACMD="$JAVA_HOME/bin/gij"
+   AC_SUBST(JAVACMD)
    AC_CHECK_HEADER(jni.h, [],
                     [AC_MSG_ERROR([jni.h could not be found. Mismatch between gcc and libgcj or libgcj-
devel missing?])], [])
 
@@ -4214,7 +4224,7 @@
 EOF
   oldJAVA_HOME=$JAVA_HOME
   if test "$JDK" = "gcj"; then
-    JAVA_HOME=; export JAVA_HOME
+    JAVACMD="$JAVA_HOME/bin/gij"; export JAVACMD
     ant_cmd="$ANT -Dbuild.compiler=gcj -buildfile conftest.xml 1>&2"
   else
     ant_cmd="$ANT -buildfile conftest.xml 1>&2"                                              

there are three parts
first patch is for set_soenv.in, second and third are configure.in.
second part is needed for general use, and third part is required to cheat ant
at configure stage. (ant doesn't know JAVACMD at configure stage, but knows
at building stage; this is what configure's job, of course)

cmc: if no objection, I'll commit it to my cws...

-    JAVA_HOME=; export JAVA_HOME
+    JAVACMD="$JAVA_HOME/bin/gij"; export JAVACMD

is wrong, we shoudn't remove JAVA_HOME and just adding JAVACMD is fine.

*** Issue 62071 has been marked as a duplicate of this issue. ***

JAVA_HOME is needed to prepare the correct JAVACMD, therefore I need to remove
that line so that I keep JAVA_HOME set:
- JAVA_HOME=; export JAVA_HOME

See the attached patch. 

If I do not remove that line ( so that JAVA_HOME=; )
configure:20440: /usr/local/apache-ant-1.6.5/bin/ant -Dbuild.compiler=gcj
-buildfile conftest.x
Error: JAVA_HOME is not defined correctly.
  We cannot execute /bin/gij
configure:20443: $? = 1
configure: Ant test failed

But I also need to export the path to gcj/gij in the environment before running
configure as follows:
export PATH=/usr/local/4.1/bin:$PATH

Without that pat to gcj/gij:

conftest:
    [javac] Compiling 1 source file

BUILD FAILED
/home/jim/build157/config_office/conftest.xml:3: Error running gcj compiler

Total time: 45 seconds
configure:20442: $? = 1
configure: Ant test failed

Created attachment 34282 [details]
configure JAVACMD for ant

Created attachment 34299 [details]
patch to configure JAVACMD - fixed spelling error

Ignore the previous patch, it needs cleaning up, attaching new one now. 
In each case I will make the patch against m157.

Created attachment 34300 [details]
configure JAVACMD - cleaned up patch

Are you sure you really want to get involved in doing all of the micro fixes in
OOo build env, instead of just fixing the outer environment to use gij as java ?
e.g. using the jpackage infrastructure ?

OOo has to detect that it is using gcj so that it can disable the sandbox that
won't build, and so it can use an alternative class in a few places but
otherwise I'd just suggest getting the jpackage style stuff working so calling
"java" just works.

No I'm not sure at all - so I appreciate your advice very much.
My observations are:
(a) gcc.gnu.org does not provide any "java" infrastructure
(b) legacy support for "java" is probably prone to breakage and likely to be
phased out as gcj matures?]
(c) on debian at least, my experience is java-gcj-compat was it is flakey,
either not working or has strange dependencies such as kaffe needed to run gjdoc.
(d) each distribution seems to have a different approach
(e) why not have the default to run with gcc/gcj "out of the box" and leave it
for distributions to handle their own any workarounds

I accept the need to be cautious with these patches as the effect on other
distribuions is hard to predict. But it is painful to carry a pile of patches
just to build with vanilla gcj. Maybe we just maintain these in a cws and it
does not get integrated?

maho: If I have understood the advice from cmc then these patches do not go
ahead because the standard "java" commands should be the defaults, with any
alternatives to be provided outside/before the OOo build. 

I have learned much about this by looking at the examples from maho and my
fiddling with the patches. It seems clear that a few environment variables
before running configure, plus a couple of symbolic links may be sufficient to
build with gcj "out of the box". 

In my case these are:
JAVACMD=/path/to/gij
JAVA=JAVACMD
JAVADOC=/path/to/gjdoc
jar-->fastjar

My idea is to stop the patches, investigate a bit more to make a concise
statement of what is required, then report to the mailing list when ready with
some suggested rules. These rules would become part of the required building tools.

cmc:
thanks for your comment.
> Are you sure you really want to get involved in doing 
> all of the micro fixes in
> OOo build env, instead of just fixing the outer environment to use > gij as java ?
> e.g. using the jpackage infrastructure ?

Could you explain a bit more? adding another dependency is not
a good idea, and if you think so, gcj should install
thier interpriter as java, gcj as javac somewhere appropreate. 
this should not be a OOo side problem. 

and from Jpackage project, one of its goal is     
> To establish an efficient and robust policy for Java software installation.
IMHO this is what debian or rpm or other packages managers should
do. Personally I want to stick to original, vanilla installation
of gcj.

So # of problems (required environment variables) are not so large, so I'd like
to go ahead. They are just only minor
problems.

well it's just that 

a) there are quite a few places that would have to be changed
b) our own redhat gcj guys reccommended that java apps just use "java" and
"javac" etc, and that the system alternatives system, as used be e.g. jpackage
should be used to set up the environment to use gij

I'm not standing in anyone way, just mentioning that it's probably easier to do
all the gij as java stuff once for the system, and not once per application.
e.g. building eclipse and other apps that need java to build

Committed to CWS maho1

set target milestone

on OOE680_m5 , the patch attached above doesn't fix this for me.

I find there is no patch required now with recent config_office.

Step (1) 
Export these to the environment before running configure 
(my gcc is configured with  --prefix=/usr/local/4.3)

export ANT_HOME=/usr/local/apache-ant-1.7.0RC1
export ANT_LIB=$ANT_HOME/lib
export PATH=$ANT_HOME/bin:/usr/local/4.3/bin:$PATH
export JAVACMD=/usr/local/4.3/bin/gij

Step (2) include these configure flags:
--with-java=gij \
--with-jdk-home=/usr/local/4.3 \
--with-ant-home=/usr/local/apache-ant-1.7.0RC1 \

then configure will run fine, ant is found and runs, and all is OK. 
The ant version does not matter - 1.6.5 or 1.7 are OK.

Works here in 2.2.0rc3
All I have is to export JAVA_HOME
and --with-jdk-home=JAVA_HOME and --with-java-home=JAVA_HOME and it works under
gcj-4.1.2

It appears that I misunderstood something here. Contrary to the bug content, I
do have gcj and java-gcj-compat installed in /usr which is why this worked for me.
Sorry for the confusion.

marking issue as fixed.

well, not really fixed, but for various reasons this won't be fixed, so i will
close it.

deleted cws maho1. I will make a new cws when it becomes clear what should be
done and agreement from QA first.