Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement new JDBC 4.0 (JDK 1.6) methods in DataSource interface [SPR-1841] #6535

Closed
spring-projects-issues opened this issue Mar 30, 2006 · 6 comments
Assignees
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Mar 30, 2006

Joshua Nichols opened SPR-1841 and commented

When compiling with the 1.6 beta, I get the following:

buildmain:
[mkdir] Created dir: /space/playpen/spring-framework-2.0-m3/target/classes
[mkdir] Created dir: /space/playpen/spring-framework-2.0-m3/target/classes/META-INF
[javac] Compiling 1390 source files to /space/playpen/spring-framework-2.0-m3/target/classes
[javac] /space/playpen/spring-framework-2.0-m3/src/org/springframework/jdbc/datasource/DelegatingDataSource.java:37: org.springframework.jdbc.datasource.DelegatingDataSource is not abstract and does not override abstract method createQueryObject(java.lang.Class) in javax.sql.DataSource
[javac] public class DelegatingDataSource implements DataSource, InitializingBean {
[javac] ^
[javac] /space/playpen/spring-framework-2.0-m3/src/org/springframework/jdbc/datasource/DriverManagerDataSource.java:71: org.springframework.jdbc.datasource.DriverManagerDataSource is not abstract and does not override abstract method createQueryObject(java.lang.Class) in javax.sql.DataSource
[javac] public class DriverManagerDataSource extends AbstractDataSource {
[javac] ^
[javac] /space/playpen/spring-framework-2.0-m3/src/org/springframework/jdbc/datasource/SingleConnectionDataSource.java:57: org.springframework.jdbc.datasource.SingleConnectionDataSource is not abstract and does not override abstract method createQueryObject(java.lang.Class) in javax.sql.DataSource
[javac] public class SingleConnectionDataSource extends DriverManagerDataSource
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 3 errors

Seemingly, the some new methods were added javax.sql.DataSource.


Affects: 2.0 M3

1 votes, 1 watchers

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Apr 4, 2006

Juergen Hoeller commented

This is expected, since we do not support compiling on JDK 1.6 yet. Of course, Spring should run nicely on JDK 1.6, just like it does on any other JDK >= 1.3. So for the time being, please use a JDK 1.5 installation for any recompilation needs.

The root cause of the error that you encountered is that JDBC 4.0, as part of JDK 1.6, extended the DataSource interface with a couple of new methods. Obviously our implementations of the DataSource interface do not implement those methods yet, since they only cover JDBC 2.1/3.0.

That said, we do plan to build on JDK 1.6, leveraging new JDK features as far as feasible (when available). Hence, I'll attach this issue to Spring 2.1, which might already build on JDK 1.6 (while still running on JDK 1.3+).

Juergen

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Apr 4, 2006

Joshua Nichols commented

I didn't really expect it to be 1.6 building to be supported. Over in Gentoo, we had ran into major issues when 1.5 came out, where numerous packages had build issues (ie enum, new XML APIs). Therefore, I hope to get a head start on 1.6.

By the way, where can I get at 2.1? I didn't see any mention of it on the homepage or in a CVS.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 3, 2007

Juergen Hoeller commented

Since the JDBC 4.0 extensions (such as the Wrapper interface that DataSource extends now) are Java 5 only, using generics etc, we can only really support them once Spring itself becomes Java 5 only. We will be able to build on JDK 1.6 with target 1.5 then, which allows us to support JDBC 4.0 explicitly. This won't happen before Spring 3.0, though.

For the time being, the entire Spring 2.x branch is going to be built on JDK 1.5, but needs to remain JDK 1.3/1.4 compatible in all core classes. Of course, Spring 2.x will perfectly run on JDK 1.6, just not be buildable on it. For recompiling Spring 2.x, please keep using JDK 1.5...

Juergen

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 3, 2007

Ismael Juma commented

Can't raw types be used to allow the code to work under JDK5, but also earlier versions?

For example, I tried adding the following signatures in a class that implements DataSource and had compiler errors in JDK6 and it compiled fine under JDK6 and using 1.4 compliance.

public boolean isWrapperFor(Class iface) throws SQLException {
    return false;
}

public Object unwrap(Class iface) throws SQLException {
    return null;
}
@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 3, 2007

Ismael Juma commented

To clarify, it compiled fine using JDK6 with 1.6 compliance and JDK6 with 1.4 compliance (I would expect it to compile fine with 1.4 and 1.4 compliance as well).

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 3, 2007

Juergen Hoeller commented

Good point... After all, the DataSource interface does not refer to specific Java-5-only types (such as enumerations) here, but rather only uses generics... So we should be able to support that earlier, and in a backwards-compatible fashion. OK, convinced, I'll keep it scheduled for Spring 2.1 and see how far we get.

Juergen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants