Thread: Drop support for jdk 1.1, 1.2 ?
As we are going to be moving to gborg, it is an opportunity to do some reorganization, one way of simplifying the driver is to drop support for some old jvm's. Is this a problem for anyone? -- Dave Cramer 519 939 0336 ICQ # 1467551
Sounds like a capital idea... There may be some of the more obscure platforms out there that still need 1.2, but if someone's still limited to 1.1 they probably should switch to perl or python...or just be content with an older driver. On Dec 29, 2003, at 2:25 PM, Dave Cramer wrote: > As we are going to be moving to gborg, it is an opportunity to do some > reorganization, one way of simplifying the driver is to drop support > for > some old jvm's. > > Is this a problem for anyone? > > -- > Dave Cramer > 519 939 0336 > ICQ # 1467551 > > > ---------------------------(end of > broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings > -------------------- Andrew Rawnsley President The Ravensfield Digital Resource Group, Ltd. (740) 587-0114 www.ravensfield.com
On 29 Dec 2003, Dave Cramer wrote: > As we are going to be moving to gborg, it is an opportunity to do some > reorganization, one way of simplifying the driver is to drop support for > some old jvm's. > > Is this a problem for anyone? This is more of a general user survey for how the driver is used and developed. With the upcoming physical move of the driver source code to http://gborg.postgresql.org/ from the main project's cvs repository we were wondering if there are other changes that should be made? For example: What JVMs does the latest version of the driver need to support? Are you likely to upgrade your 7.1 database to 7.4 without upgrading the JVM at the same time? What server versions does the latest version of the driver need to support? Are you using a driver from a new server against an older one to get some of the fixes/features or do you just download/build the driver for the server version you are on? What features are you sorely in need of that are either unimplemented or don't work as advertised? What parts of the documentation are poor or missing? Kris Jurka
Kris Jurka wrote: > > On 29 Dec 2003, Dave Cramer wrote: > > >>As we are going to be moving to gborg, it is an opportunity to do some >>reorganization, one way of simplifying the driver is to drop support for >>some old jvm's. >> >>Is this a problem for anyone? > > > This is more of a general user survey for how the driver is used and > developed. With the upcoming physical move of the driver source code to > http://gborg.postgresql.org/ from the main project's cvs repository we > were wondering if there are other changes that should be made? For > example: > > What JVMs does the latest version of the driver need to support? Are you > likely to upgrade your 7.1 database to 7.4 without upgrading the JVM at > the same time? > > What server versions does the latest version of the driver need to > support? Are you using a driver from a new server against an older one to > get some of the fixes/features or do you just download/build the driver > for the server version you are on? > > What features are you sorely in need of that are either unimplemented or > don't work as advertised? What happened to the report that 7_3 branch, possibly 7_4 were not thread-safe? One user reported concurency problems when using from Tomcat and even submitted a patch. Apparently, instance variables were used in the org.postgresql.Driver class. Nix.
On Tue, 30 Dec 2003, Nikola Milutinovic wrote: > What happened to the report that 7_3 branch, possibly 7_4 were not thread-safe? > One user reported concurency problems when using from Tomcat and even submitted > a patch. Apparently, instance variables were used in the org.postgresql.Driver > class. This has been fixed in the 7.4 and HEAD branches. The patch did not get in in time for the 7.3.5 release, so it has not gone into the 7.3 branch because we do not expect another 7.3 series release. Kris Jurka
Kris Jurka wrote: > > On 29 Dec 2003, Dave Cramer wrote: > > >>As we are going to be moving to gborg, it is an opportunity to do some >>reorganization, one way of simplifying the driver is to drop support for >>some old jvm's. >> >>Is this a problem for anyone? > > > This is more of a general user survey for how the driver is used and > developed. With the upcoming physical move of the driver source code to > http://gborg.postgresql.org/ from the main project's cvs repository we > were wondering if there are other changes that should be made? For > example: > > What JVMs does the latest version of the driver need to support? Are you > likely to upgrade your 7.1 database to 7.4 without upgrading the JVM at > the same time? > > What server versions does the latest version of the driver need to > support? Are you using a driver from a new server against an older one to > get some of the fixes/features or do you just download/build the driver > for the server version you are on? We run 1.4.2 JVMs with drivers built from CVS + patches, against 7.3.x (soon 7.4.x) servers. Dropping 1.1 support would make modifying the driver a lot easier for me. If we drop 1.1 support, can we also drop JDBC1 support? That is, not separating out a JDBC1-only build as we currently do. The main problem with merging JDBC1 and JDBC2 implementations currently is that JDBC2 depends on JDK 1.2 collection classes (java.util.Map etc). Merging that code would make bits like correct scrollable resultset support much simpler. Is there anyone using JDK >=1.2 but not JDBC2? Is there a real benefit to dropping 1.2 support? It doesn't affect me but seems a bit aggressive. The 1.2 -> 1.3 -> 1.4 API changes aren't particularly large (as used by the driver, anyway). The main argument for dropping 1.2 that I can see is that it reduces the number of JVMs that need testing. > What features are you sorely in need of that are either unimplemented or > don't work as advertised? Efficient batch insert/update support -- either a real implementation of batch updates, or a clean COPY interface. Currently, doing 100k inserts via JDBC to a remote database kills us because of the network roundtrip latency involved in doing each insert separately. I can batch the inserts into a single query in the application but that's a) nonportable [well, so is COPY] and b) ugly -- the driver should be doing this, not the app -- that's why JDBC has a batch-update interface! Robust query timeout and cancellation support. This might need API extensions since the JDBC cancel() API seems fundamentally broken. I'm not convinced that the current backend cancellation protocol is safe in all cases either (what if the cancel arrives before the query, due to a delay in the connection delivering the query?). Reducing the garbage generated by the driver (mostly double-handling of parameter/result data) would be nice to have. Our system needs low-pause collections, and the best way to reduce GC pauses is to not generate the garbage in the first place. All of the above are on my radar for eventually implementing, but I'm short on time for JDBC hacking at the moment. -O