Re: [Libreoffice] build failure in dbaccess/qa/complex/dbaccess

On Mon, 2010-11-01 at 22:53 +0100, Thomas Klausner wrote:
> /usr/pkg/java/openjdk7/bin/javac -source 1.5 -target 1.5 -classpath 
> ".:../../../unxbsdx3.pro/class:/usr/pkg/java/openjdk7/jre/lib/rt.jar:.:..../build/libreoffice-3.2.99.2/solver/330/unxbsdx3.pro/bin/ridl.jar:..../build/libreoffice-3.2.99.2/solver/330/unxbsdx3.pro/bin/unoil.jar:..../build/libreoffice-3.2.99.2/solver/330/unxbsdx3.pro/bin/jurt.jar:..../build/libreoffice-3.2.99.2/solver/330/unxbsdx3.pro/bin/juh.jar:..../build/libreoffice-3.2.99.2/solver/330/unxbsdx3.pro/bin/java_uno.jar:..../build/libreoffice-3.2.99.2/solver/330/unxbsdx3.pro/bin/OOoRunner.jar:..../build/libreoffice-3.2.99.2/solver/330/unxbsdx3.pro/bin/ConnectivityTools.jar::..../build/libreoffice-3.2.99.2/solver/330/unxbsdx3.pro/lib"
>  -d ../../../unxbsdx3.pro/class  @/tmp/mk09676h
> ./CopyTableWizard.java:182: type Optional does not take parameters
>         Optional<String> auto = new Optional<String>();

Hmm, well my understanding is that those FOO<BAR> thingies are
(relatively) new in Java, generics or whatever they're called, basically
the STL except for Java and not C++, so the initial question is probably
why do you have -source 1.5 -target 1.5 in the javac command.

I'd bet you didn't explicitly configure to use those, so back up to the
config.log and you'll probably have "checking for target java bytecode
version" and a result: 1.5, right ? So what was the line above that, the
result of the "checking the installed JDK"

Seeing as the path is /usr/pkg/java/openjdk7 it looks like a recent
javac, so it looks like that the configure.in test has defaulted to 1.5
and fallen through the configure.in test that tries to default the java
source version based off the _jdk_ver variable. There's where I'd poke
first.

C.