[Pljava-dev] zlib conflict on Debian AMD64 ???

Hi,

I suspect I have the zlib conflict, using the SUN 1.5.0 patch level7 JDK
on a Debian Etch AMD64 ,although I cannot see if the error is in
java.util.zip.Inflater.init:

DEBUG: Using integer_datetimes
DEBUG: Added JVM option string "-Djava.class.path=/usr/lib/postgresql/8.1/lib/pljava.jar"
DEBUG: Added JVM option string "-Dsqlj.defaultconnection=jdbc:default:connection"
DEBUG: Added JVM option string "vfprintf"
DEBUG: Added JVM option string "-Xrs"
DEBUG: Creating JavaVM
DEBUG: JavaVM created
DEBUG: Getting Backend class pljava.jar
WARNING: java.lang.InternalError
DEBUG: Destroying JavaVM...
DEBUG: JavaVM destroyed
ERROR: Unable to load class org/postgresql/pljava/internal/Backend using CLASSPATH '-Djava.class.path=/usr/lib/postgresql/8.1/lib/pljava.jar'

Is there a way to make sure that it is in java.util.zip.Inflater.init,
without resorting to debuggers?

If I am indeed bitten by the zlib bug, is there a way to make PL/Java
work on a Debian Etch AMD64? Should using GJC instead of using the Sun
JVM *just for PostgreSQL* work? (I cannot replace the Sun JVM as I need
to run JBoss).

TIA

--
Groeten,

Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
web: www.askesis.nl

Hi Joost,
Sun fixed the cause of the zlib conflict at patch level 5 so I doubt
that's what you're seeing. Is it possible that you compiled the
pljava.so binary for 32-bit and the JVM is a 64-bit or vice versa?

GCJ (version 4.0 and up) should work fine but so should any compatible JVM.

Regards,
Thomas Hallgren

Joost Kraaijeveld wrote:
> Hi,
>
> I suspect I have the zlib conflict, using the SUN 1.5.0 patch level7 JDK
> on a Debian Etch AMD64 ,although I cannot see if the error is in
> java.util.zip.Inflater.init:
>
> DEBUG: Using integer_datetimes
> DEBUG: Added JVM option string "-Djava.class.path=/usr/lib/postgresql/8.1/lib/pljava.jar"
> DEBUG: Added JVM option string "-Dsqlj.defaultconnection=jdbc:default:connection"
> DEBUG: Added JVM option string "vfprintf"
> DEBUG: Added JVM option string "-Xrs"
> DEBUG: Creating JavaVM
> DEBUG: JavaVM created
> DEBUG: Getting Backend class pljava.jar
> WARNING: java.lang.InternalError
> DEBUG: Destroying JavaVM...
> DEBUG: JavaVM destroyed
> ERROR: Unable to load class org/postgresql/pljava/internal/Backend using CLASSPATH '-Djava.class.path=/usr/lib/postgresql/8.1/lib/pljava.jar'
>
> Is there a way to make sure that it is in java.util.zip.Inflater.init,
> without resorting to debuggers?
>
> If I am indeed bitten by the zlib bug, is there a way to make PL/Java
> work on a Debian Etch AMD64? Should using GJC instead of using the Sun
> JVM *just for PostgreSQL* work? (I cannot replace the Sun JVM as I need
> to run JBoss).
>
> TIA
>
>

Hi Thomas,

On Thu, 2006-06-22 at 10:20 +0200, Thomas Hallgren wrote:
> Hi Joost,
> Sun fixed the cause of the zlib conflict at patch level 5 so I doubt
> that's what you're seeing. Is it possible that you compiled the
> pljava.so binary for 32-bit and the JVM is a 64-bit or vice versa?
Both are 64-bit.

What versions of zlib should be used?

My JVM has:
panoramix:/usr/lib/j2sdk1.5-sun/jre/lib/amd64# strings libzip.so | fgrep
Copyright
- deflate 1.1.3 Copyright 1995-1998 Jean-loup Gailly
inflate 1.1.3 Copyright 1995-1998 Mark Adler

> GCJ (version 4.0 and up) should work fine but so should any compatible JVM.
OK.

--
Groeten,

Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
web: www.askesis.nl

You seem to have the correct version of zlib. If you do a strings
without the fgrep you will see that all function names are prefixed with
Java_java_util_...

If possible, could you please replace your src/C/pljava/JNICalls.c with
the attached file, recompile, and then try again (retain your
log_min_messages setting of DEBUG1 or lower). The intended result is a
full java stack trace. Hopefully that will tell us more.

Regards,
Thomas Hallgren

Joost Kraaijeveld wrote:
> Hi Thomas,
>
> On Thu, 2006-06-22 at 10:20 +0200, Thomas Hallgren wrote:
>
>> Hi Joost,
>> Sun fixed the cause of the zlib conflict at patch level 5 so I doubt
>> that's what you're seeing. Is it possible that you compiled the
>> pljava.so binary for 32-bit and the JVM is a 64-bit or vice versa?
>>
> Both are 64-bit.
>
> What versions of zlib should be used?
>
> My JVM has:
> panoramix:/usr/lib/j2sdk1.5-sun/jre/lib/amd64# strings libzip.so | fgrep
> Copyright
> - deflate 1.1.3 Copyright 1995-1998 Jean-loup Gailly
> inflate 1.1.3 Copyright 1995-1998 Mark Adler
>
>
>> GCJ (version 4.0 and up) should work fine but so should any compatible JVM.
>>
> OK.
>
>
>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: JNICalls.c
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20060622/d6ec4070/attachment.c>

On Thu, 2006-06-22 at 14:51 +0200, Thomas Hallgren wrote:
> You seem to have the correct version of zlib. If you do a strings
> without the fgrep you will see that all function names are prefixed with
> Java_java_util_...

Mmmmm. I am afraid:

panoramix:/home/jkr/src/pljava-1.3.0# strings /usr/lib/j2sdk1.5-sun/jre/lib/amd64/libzip.so | grep Copyright
- deflate 1.1.3 Copyright 1995-1998 Jean-loup Gailly
inflate 1.1.3 Copyright 1995-1998 Mark Adler

> If possible, could you please replace your src/C/pljava/JNICalls.c with
> the attached file, recompile, and then try again (retain your
> log_min_messages setting of DEBUG1 or lower). The intended result is a
> full java stack trace. Hopefully that will tell us more.
>

And indeed:

DEBUG: Using integer_datetimes
DEBUG: Added JVM option string "-Djava.class.path=/usr/lib/postgresql/8.1/lib/pljava.jar"
DEBUG: Added JVM option string "-Dsqlj.defaultconnection=jdbc:default:connection"
DEBUG: Added JVM option string "vfprintf"
DEBUG: Added JVM option string "-Xrs"
DEBUG: Creating JavaVM
DEBUG: JavaVM created
DEBUG: Getting Backend class pljava.jar
java.lang.InternalError
at java.util.zip.Inflater.init(Native Method)
at java.util.zip.Inflater.<init>(Inflater.java:75)
at java.util.zip.ZipFile.getInflater(ZipFile.java:375)
at java.util.zip.ZipFile.getInputStream(ZipFile.java:320)
at java.util.zip.ZipFile.getInputStream(ZipFile.java:286)
at java.util.jar.JarFile.hasClassPathAttribute(JarFile.java:467)
at java.util.jar.JavaUtilJarAccessImpl.jarFileHasClassPathAttribute(JavaUtilJarAccessImpl.java:15)
at sun.misc.URLClassPath$JarLoader.getClassPath(URLClassPath.java:809)
at sun.misc.URLClassPath.getLoader(URLClassPath.java:293)
at sun.misc.URLClassPath.getResource(URLClassPath.java:160)
at java.net.URLClassLoader$1.run(URLClassLoader.java:192)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
WARNING: java.lang.InternalError
DEBUG: Destroying JavaVM...
DEBUG: JavaVM destroyed
ERROR: Unable to load class org/postgresql/pljava/internal/Backend using CLASSPATH '-Djava.class.path=/usr/lib/postgresql/8.1/lib/pljava.jar'

Thanks for looking into it though.

--
Groeten,

Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
web: www.askesis.nl

Joost Kraaijeveld wrote:
> On Thu, 2006-06-22 at 14:51 +0200, Thomas Hallgren wrote:
>
>> You seem to have the correct version of zlib. If you do a strings
>> without the fgrep you will see that all function names are prefixed with
>> Java_java_util_...
>>
>
>
> Mmmmm. I am afraid:
>
> panoramix:/home/jkr/src/pljava-1.3.0# strings /usr/lib/j2sdk1.5-sun/jre/lib/amd64/libzip.so | grep Copyright
> - deflate 1.1.3 Copyright 1995-1998 Jean-loup Gailly
> inflate 1.1.3 Copyright 1995-1998 Mark Adler
>
>
You still have a grep there. What's the output of the strings command
(no pipe at all)?

> And indeed:
>
> DEBUG: Using integer_datetimes
> DEBUG: Added JVM option string "-Djava.class.path=/usr/lib/postgresql/8.1/lib/pljava.jar"
> DEBUG: Added JVM option string "-Dsqlj.defaultconnection=jdbc:default:connection"
> DEBUG: Added JVM option string "vfprintf"
> DEBUG: Added JVM option string "-Xrs"
> DEBUG: Creating JavaVM
> DEBUG: JavaVM created
> DEBUG: Getting Backend class pljava.jar
> java.lang.InternalError
> at java.util.zip.Inflater.init(Native Method)
> at java.util.zip.Inflater.<init>(Inflater.java:75)
>
Interesting. You have the same version of libzip.so that I do. Perhaps
Sun forgot to mangle it on the AMD 64 platform? Anyway, there are ways
around it. To my knowledge, the only PostgreSQL utilities that make use
of the zlib are the dump/restore so one way to go around this is to
recompile the backend configured with --without-zlib. Meanwhile, I'll
see if I can get access to an AMD 64 machine...

Regards,
Thomas Hallgren

Just a sanity check. You are quite sure that your JVM really finds the
libzip.so that resides under your jre directory? Perhaps some other
libzip.so is present in your configuration and your /etc/ld.so.conf or
LD_LIBRARY_PATH lists that first?

- thomas

On Thu, 2006-06-22 at 15:16 +0200, Thomas Hallgren wrote:
> Joost Kraaijeveld wrote:
> > On Thu, 2006-06-22 at 14:51 +0200, Thomas Hallgren wrote:
> >
> >> You seem to have the correct version of zlib. If you do a strings
> >> without the fgrep you will see that all function names are prefixed with
> >> Java_java_util_...
> >>
> >
> >
> > Mmmmm. I am afraid:
> >
> > panoramix:/home/jkr/src/pljava-1.3.0# strings /usr/lib/j2sdk1.5-sun/jre/lib/amd64/libzip.so | grep Copyright
> > - deflate 1.1.3 Copyright 1995-1998 Jean-loup Gailly
> > inflate 1.1.3 Copyright 1995-1998 Mark Adler
> >
> >
> You still have a grep there. What's the output of the strings command
> (no pipe at all)?
Ah, sorry about that. Not all functions are prefixed, e.g:

panoramix:/home/jkr/src/pljava-1.3.0# strings /usr/lib/j2sdk1.5-sun/jre/lib/amd64/libzip.so | grep deflate
deflateInit2_
deflateSetDictionary
Java_java_util_zip_Deflater_deflateBytes
deflateParams
deflate
deflateReset
deflateEnd
deflate_copyright
deflateInit_
deflateCopy
- deflate 1.1.3 Copyright 1995-1998 Jean-loup Gailly

--
Groeten,

Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
web: www.askesis.nl

On Thu, 2006-06-22 at 15:23 +0200, Thomas Hallgren wrote:
> libzip.so
I have just 1 (one) libzip.so on my system.

--
Groeten,

Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
web: www.askesis.nl

Joost Kraaijeveld wrote:
> Ah, sorry about that. Not all functions are prefixed, e.g:
>
> panoramix:/home/jkr/src/pljava-1.3.0# strings /usr/lib/j2sdk1.5-sun/jre/lib/amd64/libzip.so | grep deflate
> deflateInit2_
> deflateSetDictionary
> Java_java_util_zip_Deflater_deflateBytes
> deflateParams
> deflate
> deflateReset
> deflateEnd
> deflate_copyright
> deflateInit_
> deflateCopy
> - deflate 1.1.3 Copyright 1995-1998 Jean-loup Gailly
>
>
This is really odd. The only deflate function that exists on a ia32
Linux is the deflateBytes. The others are missing. Still, both libraries
report 'deflate 1.1.3'. I guess there's good reason to report this to
Sun. I'll take care of that. Thanks for pointing this out.

Regards,
Thomas Hallgren

Ok, I've reported the bug to Sun. Their kindly informed me that they now have a 3 week (!)
average response time (unless you pay for a support contract). Sigh...

Anyway, the problem seems to be that the old functions are retained although all functions
has been added under new names. But only on amd64 and only on jdk 1.5.0.

I tried the 1.6.0 beta on amd64. The problem does not exists there so perhaps that's an
option for you? If not, perhaps you could try and copy the libzip.so from a 1.6.0 beta
release into your current 1.5.0_07.

Regards,
Thomas Hallgren

Thomas Hallgren wrote:
> Joost Kraaijeveld wrote:
>> Ah, sorry about that. Not all functions are prefixed, e.g:
>>
>> panoramix:/home/jkr/src/pljava-1.3.0# strings /usr/lib/j2sdk1.5-sun/jre/lib/amd64/libzip.so | grep deflate
>> deflateInit2_
>> deflateSetDictionary
>> Java_java_util_zip_Deflater_deflateBytes
>> deflateParams
>> deflate
>> deflateReset
>> deflateEnd
>> deflate_copyright
>> deflateInit_
>> deflateCopy
>> - deflate 1.1.3 Copyright 1995-1998 Jean-loup Gailly
>>
>>
> This is really odd. The only deflate function that exists on a ia32
> Linux is the deflateBytes. The others are missing. Still, both libraries
> report 'deflate 1.1.3'. I guess there's good reason to report this to
> Sun. I'll take care of that. Thanks for pointing this out.
>
> Regards,
> Thomas Hallgren

On Thu, 2006-06-22 at 16:40 +0200, Thomas Hallgren wrote:
> Ok, I've reported the bug to Sun. Their kindly informed me that they now have a 3 week (!)
> average response time (unless you pay for a support contract). Sigh...
>
> Anyway, the problem seems to be that the old functions are retained although all functions
> has been added under new names. But only on amd64 and only on jdk 1.5.0.
>
> I tried the 1.6.0 beta on amd64. The problem does not exists there so perhaps that's an
> option for you? If not, perhaps you could try and copy the libzip.so from a 1.6.0 beta
> release into your current 1.5.0_07.

Alas, copying did not work (and it not possible to use a beta product in
a production environment):

DEBUG: Using integer_datetimes
DEBUG: Added JVM option string "-Djava.class.path=/usr/lib/postgresql/8.1/lib/pljava.jar"
DEBUG: Added JVM option string "-Dsqlj.defaultconnection=jdbc:default:connection"
DEBUG: Added JVM option string "vfprintf"
DEBUG: Added JVM option string "-Xrs"
DEBUG: Creating JavaVM
DEBUG: JavaVM created
DEBUG: Getting Backend class pljava.jar
java.lang.UnsatisfiedLinkError: getMappedAddr
at java.util.zip.ZipFile.getMappedAddr(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:207)
at java.util.jar.JarFile.<init>(JarFile.java:132)
at java.util.jar.JarFile.<init>(JarFile.java:70)
at sun.misc.URLClassPath$JarLoader.getJarFile(URLClassPath.java:579)
at sun.misc.URLClassPath$JarLoader.<init>(URLClassPath.java:546)
at sun.misc.URLClassPath$3.run(URLClassPath.java:324)
at java.security.AccessController.doPrivileged(Native Method)
at sun.misc.URLClassPath.getLoader(URLClassPath.java:313)
at sun.misc.URLClassPath.getLoader(URLClassPath.java:290)
at sun.misc.URLClassPath.getResource(URLClassPath.java:160)
at java.net.URLClassLoader$1.run(URLClassLoader.java:192)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
WARNING: java.lang.UnsatisfiedLinkError: getMappedAddr
DEBUG: Destroying JavaVM...
DEBUG: JavaVM destroyed
ERROR: Unable to load class org/postgresql/pljava/internal/Backend using CLASSPATH '-Djava.class.path=/usr/lib/postgresql/8.1/lib/pljava.jar'

Thanks anyway for the help you offered.

--
Groeten,

Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
web: www.askesis.nl

> Alas, copying did not work (and it not possible to use a beta product in
> a production environment):
>
>
Everything is relative. I'd consider the current 1.6.0 beta far more
stable then GCJ ;-)

Regards,
Thomas Hallgren

Thomas and Joost,

I'm actually having this problem as well, though I'm running SLES9 on
x86_64 (Intel chips, not AMD, but evidently you're supposed to use the
JRE marked AMD anyway). Did you ever hear back from Sun?

Thanks,

Eric

Thomas Hallgren wrote:
>> Alas, copying did not work (and it not possible to use a beta product in
>> a production environment):
>>
>>
>>
> Everything is relative. I'd consider the current 1.6.0 beta far more
> stable then GCJ ;-)
>
> Regards,
> Thomas Hallgren
>
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/pljava-dev
>
>

Hi Eric,
Yes, Sun did reply eventually. See attached mail.

Kind regards,
Thomas Hallgren

Eric E wrote:
> Thomas and Joost,
>
> I'm actually having this problem as well, though I'm running SLES9 on
> x86_64 (Intel chips, not AMD, but evidently you're supposed to use the
> JRE marked AMD anyway). Did you ever hear back from Sun?
>
> Thanks,
>
> Eric
>
> Thomas Hallgren wrote:
>>> Alas, copying did not work (and it not possible to use a beta
>>> product in
>>> a production environment):
>>>
>>>
>> Everything is relative. I'd consider the current 1.6.0 beta far more
>> stable then GCJ ;-)
>>
>> Regards,
>> Thomas Hallgren
>>
>> _______________________________________________
>> Pljava-dev mailing list
>> Pljava-dev at gborg.postgresql.org
>> http://gborg.postgresql.org/mailman/listinfo/pljava-dev
>>
>>
>

-------------- next part --------------
An embedded message was scrubbed...
From: Sun Microsystems <IncidentUpdateDaemon at sun.com>
Subject: Re: (Incident Review ID: 734916) Still some conflicting symbols in libzip.so
Date: Thu, 06 Jul 2006 19:18:57 +0530 (GMT+05:30)
Size: 11267
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20060714/83b5fc34/attachment.mht>

I also learned that this is no longer an issue in the in the coming 8.2
version of PostgreSQL since the backend no longer links with zlib. In
fact, there's no reason for it to link with zlib in 8.1 either. So a
safe workaround is to:

1. preserve your current pg_dump/pg_restore (the only two programs that
use zlib)
2. configure using --without-zlib and rebuild and reinstall PostgreSQL
3. restore pg_dump/pg_restore

Regards,
Thomas Hallgren

Eric E wrote:
> Thomas and Joost,
>
> I'm actually having this problem as well, though I'm running SLES9 on
> x86_64 (Intel chips, not AMD, but evidently you're supposed to use the
> JRE marked AMD anyway). Did you ever hear back from Sun?
>
> Thanks,
>
> Eric
>
> Thomas Hallgren wrote:
>>> Alas, copying did not work (and it not possible to use a beta
>>> product in
>>> a production environment):
>>>
>>>
>> Everything is relative. I'd consider the current 1.6.0 beta far more
>> stable then GCJ ;-)
>>
>> Regards,
>> Thomas Hallgren
>>
>> _______________________________________________
>> Pljava-dev mailing list
>> Pljava-dev at gborg.postgresql.org
>> http://gborg.postgresql.org/mailman/listinfo/pljava-dev
>>
>>
>

On Fri, 2006-07-14 at 19:34 +0200, Thomas Hallgren wrote:
> I also learned that this is no longer an issue in the in the coming 8.2
> version of PostgreSQL since the backend no longer links with zlib. In
> fact, there's no reason for it to link with zlib in 8.1 either. So a
> safe workaround is to:
>
> 1. preserve your current pg_dump/pg_restore (the only two programs that
> use zlib)
> 2. configure using --without-zlib and rebuild and reinstall PostgreSQL
> 3. restore pg_dump/pg_restore
Alas, until I have a *working* "apt-get install" (yep, Debian and even
more simple users than developers ;-) ) I cannot use pl/java.

I do have a working (and async!!!!) trigger mechanisme using
notify/listen an additional bean and JBoss, so for the moment I am
rescued. I even doubt if I want to abandon the async part if pl/java
works....

--
Groeten,

Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
web: www.askesis.nl

Hi Thomas,
I am building PL/Java from the source along with some modifications
I'm working on. The build succeeds, and I was able to deploy pljava.so
and pljava.jar under JDK 1.5.07. In order to overcome the zlib issue, I
switched to JDK 1.6b2, because I think I've read that Java 6 can read
binaries compiled with Java 5 without problems. When I try to build
using Java 6, the compile complains about a bunch of unimplemented
methods in the JDBC interface definitions.

I then attempted to run
sqlj.install_jar('file:///......./examples.jar', 'samples', true);

It starts, and I can actually remotely connect to the JVM, but the
function dies with the exception:

ERROR: java.sql.SQLException: No such class:
org.postgresql.pljava.example.ComplexTuple

When I unzip the file, the manifest is empty, which makes sense, because
the manifest in the build tree is also empty. However, upon unzipping
examples.jar, the class is present inside of it, and less examples.jar
returns (presumably the zip manifest):

Archive: ./examples.jar
Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
0 Defl:N 2 0% 07-17-06 23:17 00000000 META-INF/
136 Defl:N 125 8% 07-17-06 23:17 b8e83a9c
META-INF/MANIFEST.MF
0 Stored 0 0% 07-17-06 23:17 00000000 org/
0 Stored 0 0% 07-17-06 23:17 00000000 org/postgresql/
0 Stored 0 0% 07-17-06 23:17 00000000
org/postgresql/pljava/
0 Stored 0 0% 07-17-06 23:17 00000000
org/postgresql/pljava/example/
1057 Defl:N 555 48% 07-17-06 23:17 670a9c4b
org/postgresql/pljava/example/SetOfRecordTest.class
1582 Defl:N 803 49% 07-17-06 23:17 5847ab8d
org/postgresql/pljava/example/ComplexTuple.class
1187 Defl:N 660 44% 07-17-06 23:17 2779804a
org/postgresql/pljava/example/Threads.class
2150 Defl:N 1183 45% 07-17-06 23:17 e50ff5ac
org/postgresql/pljava/example/ResultSetTest.class
2520 Defl:N 1253 50% 07-17-06 23:17 6081fcbf
org/postgresql/pljava/example/ComplexScalar.class
1434 Defl:N 764 47% 07-17-06 23:17 2b7503ac
org/postgresql/pljava/example/Threads$Locker.class
1060 Defl:N 643 39% 07-17-06 23:17 7cae587b
org/postgresql/pljava/example/RandomInts.class

So the class is actually there. Any thoughts on why sql_install_jar
can't find it?

Thanks,

Eric

Eric E wrote:
> Hi Thomas,
> I am building PL/Java from the source along with some modifications
> I'm working on. The build succeeds, and I was able to deploy pljava.so
> and pljava.jar under JDK 1.5.07. In order to overcome the zlib issue, I
> switched to JDK 1.6b2, because I think I've read that Java 6 can read
> binaries compiled with Java 5 without problems. When I try to build
> using Java 6, the compile complains about a bunch of unimplemented
> methods in the JDBC interface definitions.
>
>
Yes, I've seen that. Apparently the latest 1.6 introduces the JDBC 4
standard. It in turn, adds some new methods. I'll look into that with
the intention to create dummy implementations that throw unsupported
feature exceptions for now. The actual JDBC 4 will have to wait a while
longer.

> I then attempted to run
> sqlj.install_jar('file:///......./examples.jar', 'samples', true);
>
> It starts, and I can actually remotely connect to the JVM, but the
> function dies with the exception:
>
> ERROR: java.sql.SQLException: No such class:
> org.postgresql.pljava.example.ComplexTuple
>
>
This is likely to be a consequence of earlier compilation errors.

> So the class is actually there. Any thoughts on why sql_install_jar
> can't find it?
>
>
It's there, but it's broken.

I suggest you revert to Java 1.5 for now and rebuild your postgresql
using 'configure --without-zlib' to avoid the zlib issue.

Regards,
Thomas Hallgren