Re: Pl/java in 8.4 bet1 sources compilation failed

Hi community,

I'm trying to compile pl/java sources for 8.4 beta1 (for a test) but
it gives me 20 errors at the end:

"...
/home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/ObjectResultSet.java:290:
reference to updateBlob is ambiguous, both method
updateBlob(int,java.sql.Blob) in java.sql.ResultSet and method
updateBlob(int,java.io.InputStream) in java.sql.ResultSet match
this.updateBlob(columnIndex, new BlobValue(x, length));
^
/home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/ObjectResultSet.java:320:
reference to updateClob is ambiguous, both method
updateClob(int,java.sql.Clob) in java.sql.ResultSet and method
updateClob(int,java.io.Reader) in java.sql.ResultSet match
this.updateClob(columnIndex, new ClobValue(x, length));
^
/home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SQLOutputToTuple.java:35:
org.postgresql.pljava.jdbc.SQLOutputToTuple is not abstract and does
not override abstract method writeSQLXML(java.sql.SQLXML) in
java.sql.SQLOutput
public class SQLOutputToTuple implements SQLOutput
^
/home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SPIConnection.java:42:
org.postgresql.pljava.jdbc.SPIConnection is not abstract and does not
override abstract method
createStruct(java.lang.String,java.lang.Object[]) in
java.sql.Connection
public class SPIConnection implements Connection
^
/home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SQLInputFromChunk.java:40:
org.postgresql.pljava.jdbc.SQLInputFromChunk is not abstract and does
not override abstract method readRowId() in java.sql.SQLInput
public class SQLInputFromChunk implements SQLInput
^
/home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SPIStatement.java:25:
org.postgresql.pljava.jdbc.SPIStatement is not abstract and does not
override abstract method isPoolable() in java.sql.Statement
public class SPIStatement implements Statement
^
/home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SPIPreparedStatement.java:38:
org.postgresql.pljava.jdbc.SPIPreparedStatement is not abstract and
does not override abstract method setNClob(int,java.io.Reader) in
java.sql.PreparedStatement
public class SPIPreparedStatement extends SPIStatement implements
PreparedStatement
^
/home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/TriggerResultSet.java:22:
org.postgresql.pljava.jdbc.TriggerResultSet is not abstract and does
not override abstract method
updateNClob(java.lang.String,java.io.Reader) in java.sql.ResultSet
public class TriggerResultSet extends SingleRowResultSet
^
/home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SyntheticResultSetMetaData.java:20:
org.postgresql.pljava.jdbc.SyntheticResultSetMetaData is not abstract
and does not override abstract method isWrapperFor(java.lang.Class) in
java.sql.Wrapper
public class SyntheticResultSetMetaData extends AbstractResultSetMetaData
^
/home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/ClobValue.java:23:
org.postgresql.pljava.jdbc.ClobValue is not abstract and does not
override abstract method getCharacterStream(long,long) in
java.sql.Clob
public class ClobValue extends Reader implements Clob
^
/home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SPIParameterMetaData.java:16:
org.postgresql.pljava.jdbc.SPIParameterMetaData is not abstract and
does not override abstract method isWrapperFor(java.lang.Class) in
java.sql.Wrapper
public class SPIParameterMetaData implements ParameterMetaData
^
/home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SPIResultSetMetaData.java:21:
org.postgresql.pljava.jdbc.SPIResultSetMetaData is not abstract and
does not override abstract method isWrapperFor(java.lang.Class) in
java.sql.Wrapper
public class SPIResultSetMetaData extends AbstractResultSetMetaData
^
/home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SingleRowReader.java:22:
org.postgresql.pljava.jdbc.SingleRowReader is not abstract and does
not override abstract method
updateNClob(java.lang.String,java.io.Reader) in java.sql.ResultSet
public class SingleRowReader extends SingleRowResultSet
^
/home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SingleRowWriter.java:26:
org.postgresql.pljava.jdbc.SingleRowWriter is not abstract and does
not override abstract method
updateNClob(java.lang.String,java.io.Reader) in java.sql.ResultSet
public class SingleRowWriter extends SingleRowResultSet
^
/home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/BlobValue.java:20:
org.postgresql.pljava.jdbc.BlobValue is not abstract and does not
override abstract method getBinaryStream(long,long) in java.sql.Blob
public class BlobValue extends InputStream implements Blob
^
/home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SQLInputFromTuple.java:34:
org.postgresql.pljava.jdbc.SQLInputFromTuple is not abstract and does
not override abstract method readRowId() in java.sql.SQLInput
public class SQLInputFromTuple extends JavaWrapper implements SQLInput
^
/home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SPIDatabaseMetaData.java:19:
org.postgresql.pljava.jdbc.SPIDatabaseMetaData is not abstract and
does not override abstract method
getFunctionColumns(java.lang.String,java.lang.String,java.lang.String,java.lang.String)
in java.sql.DatabaseMetaData
public class SPIDatabaseMetaData implements DatabaseMetaData
^
/home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SQLOutputToChunk.java:42:
org.postgresql.pljava.jdbc.SQLOutputToChunk is not abstract and does
not override abstract method writeSQLXML(java.sql.SQLXML) in
java.sql.SQLOutput
public class SQLOutputToChunk implements SQLOutput
^
/home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SPIResultSet.java:27:
org.postgresql.pljava.jdbc.SPIResultSet is not abstract and does not
override abstract method updateNClob(java.lang.String,java.io.Reader)
in java.sql.ResultSet
public class SPIResultSet extends ResultSetBase
^
/home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SyntheticResultSet.java:21:
org.postgresql.pljava.jdbc.SyntheticResultSet is not abstract and does
not override abstract method
updateNClob(java.lang.String,java.io.Reader) in java.sql.ResultSet
public class SyntheticResultSet extends ResultSetBase
^
20 errors
make[1]: *** [.timestamp] Error 1
make[1]: se sale del directorio
`/home/ubuntu/Desktop/pljava-1.4.0/build/classes/pljava'
make: *** [pljava_all] Error 2
..."

I have 8.3 jar compild pljava, exists a way to create a function and
the server 'ignore' the lib version?

Regards,

--
Emanuel Calvo Franco
Sumate al ARPUG !
( www.arpug.com.ar)
ArPUG / AOSUG Member

Emanuel Calvo Franco wrote:
> Hi community,
>
> I'm trying to compile pl/java sources for 8.4 beta1 (for a test) but
> it gives me 20 errors at the end:

Which compiler and JDK are you using?

... and no, there isn't really any way to ignore the lib version; it
wouldn't work, because 8.3 and 8.4 aren't binary compatible for server
plugins like PL languages.

--
Craig Ringer

On Wed, 27 May 2009, Emanuel Calvo Franco wrote:

> Hi community,
>
> I'm trying to compile pl/java sources for 8.4 beta1 (for a test) but
> it gives me 20 errors at the end:

To build against 8.4 you need pljava from CVS. Also pljava can only be
built with the 1.4 or 1.5 JDK, not with the 1.6 version you are using.

Kris Jurka

2009/5/28 Kris Jurka <books(at)ejurka(dot)com>:
>
>
> On Wed, 27 May 2009, Emanuel Calvo Franco wrote:
>
>> Hi community,
>>
>> I'm trying to compile pl/java sources for 8.4 beta1 (for a test) but
>> it gives me 20 errors at the end:
>
> To build against 8.4 you need pljava from CVS.  Also pljava can only be
> built with the 1.4 or 1.5 JDK, not with the 1.6 version you are using.
>

Oh! Ok.

I don't have access to CVS, i think if a want to make my experiment i must
use 8.3.7.

Thanks Kris and Craig!

--
Emanuel Calvo Franco
Sumate al ARPUG !
( www.arpug.com.ar)
ArPUG / AOSUG Member

On Fri, May 29, 2009 at 1:19 AM, Kris Jurka <books(at)ejurka(dot)com> wrote:

>
> To build against 8.4 you need pljava from CVS.  Also pljava can only be
> built with the 1.4 or 1.5 JDK, not with the 1.6 version you are using.

is it a lot of work to make it 1.6 friendly ?
can I help?

--
GJ

another question, what about tmdb ? it requires java6, so I assumed
that jdbc is 1.6 friendly.... odd.

On Fri, May 29, 2009 at 09:48:42AM -0300, Emanuel Calvo Franco wrote:
> 2009/5/28 Kris Jurka <books(at)ejurka(dot)com>:
> >
> >
> > On Wed, 27 May 2009, Emanuel Calvo Franco wrote:
> >
> >> Hi community,
> >>
> >> I'm trying to compile pl/java sources for 8.4 beta1 (for a test)
> >> but it gives me 20 errors at the end:
> >
> > To build against 8.4 you need pljava from CVS.  Also pljava can
> > only be built with the 1.4 or 1.5 JDK, not with the 1.6 version
> > you are using.
>
> Oh! Ok.
>
> I don't have access to CVS, i think if a want to make my experiment
> i must use 8.3.7.

If you have access to a compiler but not CVS or git, you can get one
of the daily tarballs. Are you *sure* you can't use CVS or git,
though?

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

2009/5/29 David Fetter <david(at)fetter(dot)org>:
> On Fri, May 29, 2009 at 09:48:42AM -0300, Emanuel Calvo Franco wrote:
>> 2009/5/28 Kris Jurka <books(at)ejurka(dot)com>:
>> >
>> >
>> > On Wed, 27 May 2009, Emanuel Calvo Franco wrote:
>> >
>> >> Hi community,
>> >>
>> >> I'm trying to compile pl/java sources for 8.4 beta1 (for a test)
>> >> but it gives me 20 errors at the end:
>> >
>> > To build against 8.4 you need pljava from CVS.  Also pljava can
>> > only be built with the 1.4 or 1.5 JDK, not with the 1.6 version
>> > you are using.
>>
>> Oh! Ok.
>>
>> I don't have access to CVS, i think if a want to make my experiment
>> i must use 8.3.7.
>
> If you have access to a compiler but not CVS or git, you can get one
> of the daily tarballs.  Are you *sure* you can't use CVS or git,
> though?

Hey, David! :)

I don't have access yet to the git and CVS repos from these machines,
because the ports are closed. :S

Maybe the daily tarball would be usefull at this case. However, i must touch
a little to make it compilable with 1.6 java platform OR maybe downgrade
it to 1.5.

I'm doing some rare things and it will be great if I could perform these on 8.4,
despite I'll not use in 'prima facie' the new features of it.

--
Emanuel Calvo Franco
Sumate al ARPUG !
( www.arpug.com.ar)
ArPUG / AOSUG Member

David Fetter wrote:
> If you have access to a compiler but not CVS or git, you can get one
> of the daily tarballs. Are you *sure* you can't use CVS or git,
> though?
>

The problem is pljava, not postgresql. pljava doesn't have a daily
tarball or a git repo, so CVS is the only option at the moment.

Kris Jurka

Grzegorz Jaśkiewicz wrote:
> On Fri, May 29, 2009 at 1:19 AM, Kris Jurka <books(at)ejurka(dot)com> wrote:
>
>> To build against 8.4 you need pljava from CVS. Also pljava can only be
>> built with the 1.4 or 1.5 JDK, not with the 1.6 version you are using.
>
> is it a lot of work to make it 1.6 friendly ?
> can I help?
>

It depends how it's done. It would be easy to make pljava require 1.6
and just add stubs that throw unimplemented exceptions for the new
methods. Building against both 1.4/1.5 (JDBC 3) and 1.6 (JDBC 4) would
require a more complicated conditional compilation system like that
provided with the standard JDBC driver.

Kris Jurka

Grzegorz Jaśkiewicz wrote:
> another question, what about tmdb ? it requires java6, so I assumed
> that jdbc is 1.6 friendly.... odd.

I have no idea what "tmdb" is. JDK 1.6 includes the JDBC 4 API while
1.4 and 1.5 include the JDBC 3 API. So building pljava doesn't
implement all of the JDBC 4 API and can't be built with JDK 1.6. It
will run under a 1.6 JVM as long as you don't use methods that are new
in JDBC 4.

Kris Jurka

Kris Jurka wrote:
> Grzegorz Jaśkiewicz wrote:
>> On Fri, May 29, 2009 at 1:19 AM, Kris Jurka <books(at)ejurka(dot)com> wrote:
>>
>>> To build against 8.4 you need pljava from CVS. Also pljava can only be
>>> built with the 1.4 or 1.5 JDK, not with the 1.6 version you are using.
>>
>> is it a lot of work to make it 1.6 friendly ?
>> can I help?
>>
>
> It depends how it's done. It would be easy to make pljava require 1.6
> and just add stubs that throw unimplemented exceptions for the new
> methods. Building against both 1.4/1.5 (JDBC 3) and 1.6 (JDBC 4) would
> require a more complicated conditional compilation system like that
> provided with the standard JDBC driver.

Perhaps a stupid question, but isn't the `-source' parameter to javac
intended to mask new features and such for just the purpose of compiling
older sources on a new JDK?

--
Craig Ringer

Craig Ringer wrote:

> Perhaps a stupid question, but isn't the `-source' parameter to javac
> intended to mask new features and such for just the purpose of compiling
> older sources on a new JDK?
>

The -source argument only controls language features, not
interface/class definitions. java.sql.* provides interfaces that
drivers must implement. When they add new functions to those interfaces
you have to implement those, otherwise the compile fails saying that the
class doesn't implement the specified interface. Sometimes you can
implement new interface functions so that the code can compile in either
version, but not always. Consider the following two cases:

1) JDBC4 has added a new method to java.sql.Array named "void free()".
This can be implemented for JDBC3 and there's no problem that the JDBC3
class implements an additional method that's only required by JDBC4.
The code can be compiled against either JDK version.

2) JDBC4 has added a new interface, java.sql.SQLXML, and added methods
to java.sql.ResultSet to retrieve SQLXML objects. You can't add a
method "SQLXML getSQLXML(int)" to your JDBC3 class because it doesn't
know anything about SQLXML at all because it isn't defined by JDBC3.
For this we must add code that is only compiled if we're building with a
JDK that has JDBC4.

The JDBC driver does this by defining a hierarchy:

AbstractJdbc2ResultSet
|__Jdbc2ResultSet
|__AbstractJdbc3ResultSet
|__Jdbc3ResultSet
|__AbstractJdbc4ResultSet
|__Jdbc4ResultSet

AbstractJdbc4ResultSet will have the getSQLXML method and the
JdbcXResultSet classes will be just stubs that officially implement the
java.sql.ResultSet interface.

If we're building a JDBC3 driver we'll compile AbstractJdbc2ResultSet,
AbstractJdbc3ResultSet, and Jdbc3ResultSet and when asked for a
ResultSet instance we'll return a Jdbc3ResultSet. When building a JDBC4
driver we'll then exclude Jdbc3ResultSet and compile
AbstractJdbc4ResultSet and Jdbc4ResultSet and when asked for ResultSet
instance we'll return a Jdbc4ResultSet.

By using this inheritance we can conditionally compile entire classes
which is easy to do with ant rather than trying to implement something
like #ifdef which is ugly to do with ant's copy with filtering task.

Unfortunately pljava currently has no such infrastructure.

Kris Jurka

Kris Jurka wrote:
> Craig Ringer wrote:
>
>> Perhaps a stupid question, but isn't the `-source' parameter to javac
>> intended to mask new features and such for just the purpose of compiling
>> older sources on a new JDK?
>>
>
> The -source argument only controls language features, not
> interface/class definitions. [snip]

Ah. Thanks for that very enlightening and helpful explanation - I really
appreciate your taking the time.

It's interesting that the JDK presents these issues to driver
developers, but I see how there's no easy way around it given that Java
offers no way to declare default implementations of methods in
interfaces (iow: no multiple inheritance) so the JDBC interfaces can't
provide stubs.

Argh, if only Java had scope-based object lifetime with prompt
finalization (think C++ "stack-based" objects) and multiple inheritance...

--
Craig Ringer