[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