[jbossts-issues] [JBoss JIRA] Commented: (JBTM-419) Hardcoded "1.5" java version check in com\arjuna\ats\internal\jdbc\ConnectionManager.java won't work on Java 1.6
Mauro Molinari (JIRA)
jira-events at lists.jboss.org
Wed May 6 06:00:46 EDT 2009
[ https://jira.jboss.org/jira/browse/JBTM-419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12465958#action_12465958 ]
Mauro Molinari commented on JBTM-419:
-------------------------------------
>Umm, not so. In a strongly typed language if something 'implements SomeInterface' then code can reasonably call methods on that interface. That's what interface declarations are for. Adding a requirement that you call some method to determine if the claim of 'implements SomeInterface' is actually true or not is missing the point of the type system.
I see and I agree with you generally speaking. However, in this scenario this can be a non-problem in many circumstances: if our application has to work with Java 1.5, at development time we're coding and compiling against Java 5 APIs, so we don't have the risk to call Java6-specific methods on the JDBC interfaces. We would be silly if we were coding against Java 6 APIs...
Regarding your last question: yes, I think that JBossTS could use the JDBC3 implementation even when running under an execution environment and virtual machine coming from a Java 6 distribution. This has nothing to do with the fact that, as of today, JBossTS APIs are compliant with at most JDBC3-Java5. Compile time and run time are two different things and, fortunately, Java is designed so that they are not so tighten that a compile time constraint necessarily translates into a run time constraint. This is one of those cases.
If your argument were correct, then I ask you: why JBossTS is using a JDBC2 implementation when running under Java6? It would suffer of the exact same problems of a JDBC3 implementation, wouldn't it? However, I can state for sure that there are no problems at all! And I can't see why the JDBC3 implementation should have instead.
> Hardcoded "1.5" java version check in com\arjuna\ats\internal\jdbc\ConnectionManager.java won't work on Java 1.6
> ----------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-419
> URL: https://jira.jboss.org/jira/browse/JBTM-419
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JTA
> Affects Versions: 4.4.0.GA
> Environment: Sun's J2SE DevKit 1.6u10
> Reporter: Sergey Proskurnya
> Assignee: Jonathan Halliday
> Priority: Minor
> Fix For: 4.7.0
>
>
> There is a hard-coded version check in com.arjuna.ats.internal.jdbc.ConnectionManager in "create (String dbUrl, Properties info)" method:
> --------------------------------------------------------------------------------------------------------------------------
> ...
> line 116:
> if(System.getProperty("java.specification.version").equals("1.5"))
> {
> // the 1.5 (JDBC3) wrapper version is loaded dynamically because classloading
> // it on earlier versions of the platform is not possible.
> ....
> }
> --------------------------------------------------------------------------------------------------------------------------
> That piece of code will not work correctly on Java 1.6, because System.getProperty("java.specification.version") returns "1.6" on Java 1.6.
> It is needed to parse the result of System.getProperty("java.specification.version") and compare major and minor versions separately.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jbossts-issues
mailing list