Is there a Database API specification for Java that is similar to what exists for Python (PEP249).
I'd like to make an application that can be used to connect to databases, universally, without worrying about the database engine type.
Yes, such an API exists and - AFAIK - it predates Python efforts at standardization. This specification and its API is called JDBC or Java DataBase Connectivity. The current version is JDBC 4.2 (with JDBC 4.3 currently in the pipeline), also identified as JSR 221: JDBCTM 4.0 API Specification maintenance release 2.
You can find the specification document at https://jcp.org/en/jsr/detail?id=221
The interfaces of the API are included in main Java API. See the packages java.sql and javax.sql.
See the Java Tutorial Trail: JDBC(TM) Database Access for an introduction.
A JDBC specification is tied to a Java version, so:
Java 9: JDBC 4.3
Java 8: JDBC 4.2
Java 7: JDBC 4.1
Java 6: JDBC 4.0
... earlier versions are not that interesting anymore
JDBC versions are generally additive, so features in earlier versions are carried over into newer version, and - bar some early mistakes - are usually not deprecated. Sometimes minor clarifications or semantic changes can be made in newer versions of the specification.
Be aware that features in newer JDBC versions are (usually) only accessible if the driver actually implements that JDBC version.
Disclosure: I am a member of the JDBC Expert Group
Related
Our application is using JDK7, websphere and is hosted on AIX box.
Recently we upgraded to oracle 19c from 12c. After this, application server does not start.
We do not see any error in startup logs. All application modules do not load, hence server does not come up.
We tried commenting all unnecessary modules in ILSStartupDef.xml, but same issue.
JDBC jar that we are using is ojdbc7-12.1.0.2.0-p0.jar.
Can someone please help ? Any config changes that we may be missing ? We dont want to upgrade to java8 unless its absolutely necessary.
Can you confirm that the database connexion test on the console is working properly ?
Note : Upgrading to Java 8 can be challenging, but Java 7 is no more supported.
Based on this document from IBM :
https://www.ibm.com/support/pages/websphere-application-server-support-policy-jdbc-databases-and-drivers
That being said, yes we do support Oracle 18C and 19C in WebSphere Application Server 8.5.5.X and V9.0.x but you must aware of this following.
We dont test WebSphere Application Server with each and every release of Oracle database. Please make sure you do the test before moving to production.
I believe the oracle 18C or later driver supports java 8 or later release only, if so please make sure WAS java level is also java 8. Java 8 is supported in 8.5.5.9 or later release.
If you ever see this issue, please consider upgrading WAS and do the test again. This issue is fixed in 8.5.5.13 or later release.
Good Luck
From Oracle perspective, please check this post :
Oracle 19c compatibility with jdk7
According to the Oracle JDBC FAQ (Question "What are the Oracle JDBC releases Vs JDK versions?"), only the Java versions you listed (Java 8 to 11) are supported for Oracle 19c.
I would advise to do the assessment for migrating to Java 8, using Transformation Advisor.
Good Luck
If you have upgraded the database server version to 19c then, it is recommended to upgrade the JDBC driver to the same version. So, you should use 19c JDBC driver.
19c JDBC driver requires JDK8 or JDK11. So, it is time to upgrade the JDK version as well as the JDBC driver as well.
I am trying to make a JDBC call to a SAP HANA database. My Java code version is Java 11. I am using ngdbc 2.11.14 HANA jdbc driver. I am getting below error.
Unexpected Java class loaded under Java version 11 (maximum supported version is 8): java.lang.AssertionError
java.lang.AssertionError: Unexpected Java class loaded under Java version 11 (maximum supported version is 8)
at com.sap.db.jdbc.DriverSapDB._checkJavaVersion(DriverSapDB.java:2179)
at com.sap.db.jdbc.DriverSapDB.checkJavaVersionMaximum8(DriverSapDB.java:2154)
Also I can see in decompiler, below code in Driver.java file, which checks for maximum Java version 8. Does this mean SAP HANA JDBC driver does not support Java 11?
public class Driver extends DriverSapDB {
static {
checkJavaVersionMaximum8();
}
The SAP HANA JDBC driver is a multi-release JAR. From my basic understanding, this means that it carries separate class files for Java <= 8 and for Java > 8.
Short answer to your question: Yes, the SAP HANA JDBC driver does support Java 11 (and above)!
It seems your code (or framework) fetches the incorrect class files for Java 8 internally. I've had an issue in the past which resulted in the same error message that you see. For me, this has happened in the context of using OSGi and due to a bug with multi-release JARs in Apache Felix.
You can read the details about my issue (..which may or may not be different from yours) in this thread.
In release 3.7.8, it was stated that the support was added for DB2 and DB2/400. However, in 3.14.0, it was stated that the experimental support was discontinued.
Going through the API, it was noted that there's no dialect for DB2. As such, I guess the support for DB2 was removed.
I would like to find out whether DB2 support is still in the plan for Javers or abandoned?
Thanks.
We have abandoned support for DB2 database, as we can't find a way how to run integration tests for it.
We are migrating applications from Websphere 8.5.5.2 to 8.5.5.11 with JDK 8.
We connecting 3 different databases Oracle,DB2,Sybase and currently using following drivers for the same.
DB2: db2jcc.jar,db2jcc_license_cu.jar,db2jcc_license_cisuz.jar
Oracle: ojdbc14.jar
Sybase:jconn4.jar
Dose this drivers will support JDK 8 or do we need to use different version of jars. We are bale to connect DB with this jars in WAS-8.5.5.11 but does this cause any connection issues when load was high.
To support Java-8 with Db2 jdbc , it is best to use a recent version of the Db2-driver files, at least higher than V10.5-fixpack7 or higher.
To learn which jdbc-driver-version gets supplied with which Db2-client version, check here. You can download latest drivers from that page (IBM registration required).
Looking at various Oracle doc (cited below) it looks like you should plan to move up to a newer version of the Oracle JDBC driver for Java 8.
Regarding ojdbc14.jar which you were using, Oracle documentation states that it is for JDK 1.4 and JDK 1.5
On the Oracle JDBC faq, under the section titled "What are the Oracle JDBC releases versus JDK versions?" it indicates to use ojdbc6, ojdbc7, or ojdbc8 with Java 8 depending on which Oracle database version you have.
I am working on legacy code that uses JPA where the code still calls setFormOfUse() for each database parameter of type NCHAR, NVARCHAR.
I am aware that there was a time that this was required.
I am aware
that there was a time after that when one could tweak the default
setting so that it does not have to be caled for each binding.
Is it still necessary to invoke the setFormOfUse() at this point of time (dec 2016) with the latest JDBC drivers? From which JDBC/Oracle versions one can do what? I can only find snippets of information unrelated from the versions.
Edit 1 - Related Questions
Getting Hibernate and SQL Server to play nice with VARCHAR and NVARCHAR
Hibernate with NVARCHAR2
Using Types.NVARCHAR with oracle JDBC driver to work with Cyrillic chars: This gives a hint that 'setFormOfUse()' is necessary until ojdbc driver 11.2.0.1 (jul. 2009) and you can use setNString from driver 11.2.0.2 (aug 2010).
Hibernate with NVARCHAR2 This question is interesting because of the Hibernate version information.
Edit 2 - JDBC Spec
I searched the JDBC specs and I found this information:
JDBC 3.0 (JSR 54; 2002) Nothing in there about NCHAR, NVARCHAR, NCLOB, ...
JDBC 4.0 (JSR 221; 2006) This mentions setNString() and others. So the earliest year that 'setNString' could replace 'setUseOf' would be 2006. So I will now look at the Hibernate releases and Oracle driver releases from 2006 to find the earliest setNString support (if it is supported).
Edit 3 - Conclusion
Conclusions
From Oracle ojdbc-11.2.0.2 (aug 2010) and higher you can use the standard JDBC 'setNString()' in stead of the Oracle specific 'setFormOfUse()'.
If using Hibernate ORM, it is supported from version 4.1.10 and above.
Implications
If using ojdbc-11.2.0.1 (jul 2009) you should write your own OracleDialect and explicitly call 'setFormOfUse()'.
If using ojdbc-11.2.0.2 (aug 2010) or higher + Hibernate < 4.1.10 you have to write your own OracleDialect and call 'setNString()'.
If using ojdbc-11.2.0.2 or higher + Hibernate >= 4.1.10 you don't have to do anything, the conversion will work out-of the box.