ebuild for jdbc-postgresql-8.2_p505 depends on JDK 1.4 or 1.5. It is compatible with JDK 1.6 since version 8.2-504. I have built it successfully using modified ebuild.
I'm not sure where you are shooting :-) Building it using different JDKs produces different jars. With JDK 1.4 it is JDBC3 driver, with JDK 1.5 it is also JDBC3 driver but also with some JDBC3G stuff (don't ask me, I do not know what's that good for), with JDK 1.6 it is JDBC4 driver but as this page says: http://jdbc.postgresql.org/download.html "JDK 1.6 - JDBC4. Support for JDBC4 methods is limited. The driver builds, but the majority of new methods are stubbed out." So the result using JDK 1.6 is very close to the result when building with JDK 1.5. Anyway I plan to allow users to build the driver also with JDK 1.6 but not decided yet whether is would be through 'java6' USE flag or through 'jdbc4' USE flag. 'java6' USE flag would be safe wrt future as building the driver with JDK 1.7 might also be JDBC4 driver but again with some extra stuff as it is already with JDK 1.4 and JDK 1.5 so 'java7' will come handy. 'jdbc4' USE flag is about what the user gets so it is more intuitive but not safe wrt future releases of JDK. Any suggestions?
(In reply to comment #1) > > 'jdbc4' USE flag is about what the user gets so it is more intuitive but not > safe wrt future releases of JDK. > This makes no sense to me.
Let me see if I can explain a little bit why jdbc4 might make sense. First off we used to label each as jdbc2, jdbc3, and so one. That is still valid if it refers to a specific type of jdbc driver. If it builds only one for a given set of sources Some drivers can build more than one type. Jaybird does that via the jni use flag. Although that might make more sense as jdbc2 with the default being a jdbc4 driver. Now if we introduce a jdbc* flag, we might need to add a modifier just to be clear we are talking about version vs type jdbc_v2 or jdbc_t2, etc. Ok now back to why jdbc* would make sense vs java*. Just because Java 1.6 has JDBC spec version 4.0. 1.6 can still build a driver written to JDBC spec version 3.0 or etc. That being said a v 3.0 driver could still run in 1.6, just as I am using Jaybird now. Pretty sure there is nothing in the specs to prevent this. So a package very well might have say java5 java6 jdbc_t2 jdbc_v3 jdbc_v4 USE flags. With possible say one of the jdbc_v3 being a default so not present. Might default with a 3.0 spec, and offer a 4.0 one via flag, and etc. There very well could be use for a jdbc* USE flag and I could see it being used with java* flags at the same time. Maybe I want a 1.5 bytecode version 4.0 driver. Not sure if that's possible, but the JDBC specs aren't usually bound to anything source wise. It's more about functionality and how JDBC drivers should be written to behave. For those that even adhere to the JDBC spec versions :) Confused yet ;)
(In reply to comment #3) > > Ok now back to why jdbc* would make sense vs java*. Just because Java 1.6 has > JDBC spec version 4.0. 1.6 can still build a driver written to JDBC spec > version 3.0 or etc. That being said a v 3.0 driver could still run in 1.6, just > as I am using Jaybird now. Pretty sure there is nothing in the specs to prevent > this. > Or not as Sun only guaranties ABI compatibility and the jdbc drivers build against the SQL APIs in the JDK. I think we already have cases where the 1.6 SQL api makes the ebuilds have || ( 1.5 1.4 )
(In reply to comment #4) > > Or not as Sun only guaranties ABI compatibility and the jdbc drivers build > against the SQL APIs in the JDK. I stand corrected, although even though it's ABI compatible. Looking else where I saw some problems when people were say using PostgreSQL JDBC v 3 driver with a 1.6 jdk and having issues. http://archives.postgresql.org/pgsql-jdbc/2007-04/msg00008.php > I think we already have cases where the 1.6 > SQL api makes the ebuilds have || ( 1.5 1.4 ) Correct, and when I added 1.6 to jaybird, it fails to build, even with a source/target of 1.4. Although after what I saw else where, we might want to make sure the jre in rdep matches. ATM jaybird requires like >=1.4 jre. At the present moment I am not having any problems running a JDBC v 3.0 Jaybird driver under 1.6 vms. But if I were to use some of the more advanced features, it's likely they would break, just like PostgreSQL. So java* flags make sense and remain, jdbc* ones for version don't make sense. That's handled by java* flag. Although jdbc* might make sense for types vs something like jni.
Looking at your posts, I think java6 would be appropriate here and that was the solution I tended to. I just mentioned the other option, 'jdbc4' USE flag which is what Betelgeuse suggested when we talked about it on irc. Just a note to the building and running JDBC drivers. IMO it is not possible to build JDBC3 driver with JDK 1.6 if the driver does not implement the new methods from JDBC4. On the other hand, there should be no problem to run JDBC3 driver using JDK 1.6 as far as only the JDBC3 methods and classes are used from the code (as wltjr mentioned).
Since jdbc-postgresql-8.3_p603-r1 it is possible to compile the driver against JDK 1.6 too which causes the driver to be JDBC version 4. It is still possible to build the driver against JDK 1.5 (USE flag java5) or against JDK 1.4 (no USE flag).
