[
https://jira.jboss.org/jira/browse/JBTM-419?page=com.atlassian.jira.plugi...
]
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