Thread: Moving from Java 1.5 to Java 1.6
We have an application which uses postgresql 7.4.5.
Now when we moved to Java 1.6, we are seeing lots of jdbc driver related compilation issues like shown at end of this email.
Question is can we just only upgrade jdbc driver alone or its better to move completely to a new postgres version. ?
Are there any docs that explain about how to migrate ?
thanks
Swayam
./org/postgresql/Driver.java:393: cannot find symbol
symbol : constructor Jdbc4Connection(java.lang.String,int,java.lang.String,java.lang.String,java.util.Properties,java.lang.String)
location: class org.postgresql.jdbc4.Jdbc4Connection
return new org.postgresql.jdbc4.Jdbc4Connection(host(props), port(props),
^
./org/postgresql/jdbc2/AbstractJdbc2Statement.java:734: cannot find symbol
symbol : method addTimerTask(java.util.TimerTask,int)
location: class org.postgresql.Driver
Driver.addTimerTask( cancelTimer, seconds * 1000);
^
./org/postgresql/jdbc3/Jdbc3Array.java:15: org.postgresql.jdbc3.Jdbc3Array is not abstract and does not override abstract method free() in java.sql.Array
public class Jdbc3Array extends org.postgresql.jdbc2.AbstractJdbc2Array implements java.sql.Array
^
./org/postgresql/jdbc3/Jdbc3Blob.java:13: org.postgresql.jdbc3.Jdbc3Blob is not abstract and does not override abstract method getBinaryStream(long,long) in java.sql.Blob
public class Jdbc3Blob extends org.postgresql.jdbc3.AbstractJdbc3Blob implements java.sql.Blob
^
./org/postgresql/jdbc3/Jdbc3Statement.java:19: org.postgresql.jdbc3.Jdbc3Statement is not abstract and does not override abstract method isPoolable() in java.sql.Statement
class Jdbc3Statement extends AbstractJdbc3Statement implements Statement
^
./org/postgresql/jdbc3/Jdbc3PreparedStatement.java:12: org.postgresql.jdbc3.Jdbc3PreparedStatement is not abstract and does not override abstract method setNClob(int,java.io.Reader) in java.sql.PreparedStatement
class Jdbc3PreparedStatement extends Jdbc3Statement implements PreparedStatement
^
./org/postgresql/jdbc3/Jdbc3CallableStatement.java:13: org.postgresql.jdbc3.Jdbc3CallableStatement is not abstract and does not override abstract method setNClob(java.lang.String,java.io.Reader) in java.sql.CallableStatement
class Jdbc3CallableStatement extends Jdbc3PreparedStatement implements CallableStatement
^
./org/postgresql/jdbc3/Jdbc3Connection.java:20: org.postgresql.jdbc3.Jdbc3Connection is not abstract and does not override abstract method createStruct(java.lang.String,java.lang.Object[]) in java.sql.Connection
public class Jdbc3Connection extends org.postgresql.jdbc3.AbstractJdbc3Connection implements java.sql.Connection
^
./org/postgresql/jdbc3/Jdbc3Clob.java:11: org.postgresql.jdbc3.Jdbc3Clob is not abstract and does not override abstract method getCharacterStream(long,long) in java.sql.Clob
public class Jdbc3Clob extends org.postgresql.jdbc3.AbstractJdbc3Clob implements java.sql.Clob
^
./org/postgresql/jdbc3/Jdbc3DatabaseMetaData.java:11: org.postgresql.jdbc3.Jdbc3DatabaseMetaData 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 Jdbc3DatabaseMetaData extends org.postgresql.jdbc3.AbstractJdbc3DatabaseMetaData implements java.sql.DatabaseMetaData
^
./org/postgresql/jdbc3/Jdbc3ParameterMetaData.java:13: org.postgresql.jdbc3.Jdbc3ParameterMetaData is not abstract and does not override abstract method isWrapperFor(java.lang.Class<?>) in java.sql.Wrapper
public class Jdbc3ParameterMetaData extends AbstractJdbc3ParameterMetaData implements ParameterMetaData {
^
./org/postgresql/jdbc3/Jdbc3ResultSet.java:21: org.postgresql.jdbc3.Jdbc3ResultSet is not abstract and does not override abstract method updateNClob(java.lang.String,java.io.Reader) in java.sql.ResultSet
public class Jdbc3ResultSet extends org.postgresql.jdbc3.AbstractJdbc3ResultSet implements java.sql.ResultSet
^
./org/postgresql/jdbc3/Jdbc3ResultSetMetaData.java:12: org.postgresql.jdbc3.Jdbc3ResultSetMetaData is not abstract and does not override abstract method isWrapperFor(java.lang.Class<?>) in java.sql.Wrapper
public class Jdbc3ResultSetMetaData extends org.postgresql.jdbc2.AbstractJdbc2ResultSetMetaData implements java.sql.ResultSetMetaData
^
./org/postgresql/ssl/MakeSSL.java:63: cannot find symbol
symbol : method getHost()
location: class org.postgresql.core.PGStream
Socket newConnection = factory.createSocket(stream.getSocket(), stream.getHost(), stream.getPort(), true);
^
./org/postgresql/ssl/MakeSSL.java:63: cannot find symbol
symbol : method getPort()
location: class org.postgresql.core.PGStream
Socket newConnection = factory.createSocket(stream.getSocket(), stream.getHost(), stream.getPort(), true);
On Thu, Oct 04, 2012 at 12:22:55PM +0530, Swayam Prakash Vemuri wrote:
> Hi
>
> We have an application which uses postgresql 7.4.5.
You have a very large problem. The 7.4 series went out of support two
years ago at 7.4.30, which means that you have known data corruption
and crash bugs, and would even if you were to upgrade to 7.4.30
immediately.
You need to upgrade to a supported version and put systems in place to
do upgrades of every component in the system on a regular basis, as
they all have finite lifetimes.
> Now when we moved to Java 1.6, we are seeing lots of jdbc driver related
> compilation issues like shown at end of this email.
Those appear to be Java issues pretty strictly.
> Question is can we just only upgrade jdbc driver alone or its better to
> move completely to a new postgres version. ?
>
> Are there any docs that explain about how to migrate ?
Use 9.2.1's pg_dump to get your data out of the running 7.4 database
and then restore it to the 9.2.1 database.
For each database on the 7.4 machine, run the following on the 9.2
machine:
pg_dump -h name.of.7.4.machine.com -U postgres -Fc --file=mydb.dump mydb
To restore on the 9.2 machine:
pg_restore -C mydb.dump
Hope this helps.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
On 10/04/2012 10:13 AM, David Fetter wrote: > For each database on the 7.4 machine, run the following on the 9.2 > machine: > > pg_dump -h name.of.7.4.machine.com -U postgres -Fc --file=mydb.dump mydb Don't forget the global settings: pg_dumpall -g -U postgres -f globals.sql And you should probably restore it *before* the rest of the databases, since it contains users, groups, and so on, necessary for permissions to be correct following the database restore. pg_restore -U postgres globals.sql -- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604 312-444-8534 sthomas@optionshouse.com ______________________________________________ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
The appropriate list for this is the jdbc list: pgsql-jdbc@postgresql.org
-
Achilleas Mantzios
IT DEPT
Swayam Prakash Vemuri, 04.10.2012 08:52: > Hi > > We have an application which uses postgresql 7.4.5. > > Now when we moved to Java 1.6, we are seeing lots of jdbc driver related compilation issues like shown at end of this email. > Not only are you using an outdated (and unsupported) PostgreSQL version. You are also moving to a Java version that is soon to be de-supported. Why not move to 1.7 directly?
On 10/04/12 11:21 PM, Thomas Kellerer wrote: > You are also moving to a Java version that is soon to be de-supported. Java is supported? only if you mean the non-stop stream of updates brought on by web exploit exposures. if you're using Java as a server side application development environment, whats 'supported' mean ? frankly, at least from our perspective, Java 7 has been a no-fly so far. it brings nothing to the table we're interested in, just more Oracle induced nonsense. -- john r pierce N 37, W 122 santa cruz ca mid-left coast
John R Pierce, 05.10.2012 08:34: >> You are also moving to a Java version that is soon to be >> de-supported. > > Java is supported? only if you mean the non-stop stream of updates > brought on by web exploit exposures. Yes it is. In a similar way as PostgreSQL is "supported". > if you're using Java as a server side application development > environment, whats 'supported' mean ? There are versions where Oracle will apply bugfixes and there are version where they will not. It's not only about security fixes for the Browser plugin-in (which I frankly think is totally useless), but there are also fixes to the whole JDK and Java API which could well affect server apps. Think IPv6 - AFAIK that will not be available for older Java versions. > frankly, at least from our perspective, Java 7 has been a no-fly so > far. it brings nothing to the table we're interested in, just more > Oracle induced nonsense. I beg to differ. There are some new features in the language that are really nice. And also several new technologies will not be available on the old Java platforms (think Tomcat 7, JavaEE 6 and so on) The same way you should stay up-to-date with a PostgreSQL release you should with your Java development environment (even if you don't really need or use the new features)
John R Pierce, 05.10.2012 08:34: > On 10/04/12 11:21 PM, Thomas Kellerer wrote: >> You are also moving to a Java version that is soon to be de-supported. > > Java is supported? Found the link as well: http://www.oracle.com/technetwork/java/javase/eol-135779.html Quote: "After February 2013, Oracle will no longer post updates of Java SE 6 to its public download sites"
On 10/04/2012 02:52 PM, Swayam Prakash Vemuri wrote: > Hi > > We have an application which uses postgresql 7.4.5. Wow. Upgrade time on two levels: - You're running a fossilized point release. The latest 7.4.x is 7.4.30, 25 patch-levels after yours, and came out in October 2010 vs the August 2004 (!!) release date of your version. You're missing SIX YEARS OF BUG FIXES. - 7.4.x is unsupported. No future releases will be made with bug fixes or compatibility improvements. Upgrade urgently, because it's only going to get more difficult. Read the release notes from every .0 version between 7.4 and 9.1 or 9.2 to find possible compatibility issues you may face. Pay particular attention to the bytea_output change (if you use bytea), to standard_conforming_strings, and to the removal of implicit casts to text. > Now when we moved to Java 1.6, we are seeing lots of jdbc driver related > compilation issues like shown at end of this email. You shouldn't need to compile PgJDBC; there are pre-built binaries provided for JDBC3 and JDBC4 versions of the platform. You haven't said which version of PgJDBC you are updating *from* or *to*, making it hard to help you. The latest PgJDBC should be fine in Java 1.5, 1.6 or 1.7 and should work against Pg 8.3 or newer, and may also work on older versions of Pg as well. There's code in there for 7.3 and older. You cannot reasonably expect an ancient PgJDBC to compile on a new Java, or a new PgJDBC on a new Java to support a truly ancient Pg like 7.4. -- Craig Ringer