bitronix.tm.osgi.Activator class is incompatible with JDK5

[rankinc]

The Activator class contains these lines:

FileReader fileReader = new FileReader(cfgFile);
try {
    btmProperties.load(fileReader);
}
finally {
    fileReader.close();
}

Unfortunately, the Properties.load(Reader) API only exists since JDK6. To be compatible with JDK5 (which is your declared target), you need to use a FileInputStream instead of a FileReader.

Or you could switch to JDK6, now that JDK8 has been released.

On the positive side, this does appear to be the only JDK6 issue in the project.

[vladmihalcea]

Hi,

I am not sure how many are still running on JDK 5 which reached it "end of life" already: http://www.oracle.com/technetwork/java/javase/1-5-137169.html.
Maybe the minimum supported JVM should be updated to 1.6

Vlad

On Tuesday, April 1, 2014 11:40 AM, rankinc notifications@github.com wrote:

The Activator class contains these lines:
FileReader fileReader = new FileReader(cfgFile);
try { btmProperties.load(fileReader);
}
finally { fileReader.close();
}
Unfortunately, the Properties.load(Reader) API only exists since JDK6. To be compatible with JDK5 (which is your declared target), you need to use a FileInputStream instead of a FileReader.
On the positive side, this does appear to be the only JDK6 issue in the project.
Or you could switch to JDK6, now that JDK8 has been released.
—
Reply to this email directly or view it on GitHub.

[lorban]

BTM 2.1.x' target was JDK 1.5 but I think we can reasonably make 3.0.0 require JDK 1.6.

[rankinc]

I wouldn't object to that ;-). That would mean that we could also replace constructs such as:

 throw (SQLException) new SQLException("unilateral rollback of " + this).initCause(ex);

with:

throw SQLException("unilateral rollback of " + this, ex);

And that we wouldn't need to use Reflection in order to invoke Connection.isValid().

Not to mention proper use of @OverRide...

[brettwooldridge]

You still need reflection because even though Java 6 defines the isValid()
signature, many drivers are only JDBC2/3 compliant (pre-Java 6) and do not
implement the method. So at runtime an exception is thrown when isValid()
is invoked. I forget which, maybe AbstractMethodException or something.
Anyway, we can't get rid of the reflection for probably a long time to
come.

On Tue, Apr 1, 2014 at 2:10 AM, rankinc notifications@github.com wrote:

I wouldn't object to that ;-). That would mean that we could also replace
constructs such as:

throw (SQLException) new SQLException("unilateral rollback of " + this).initCause(ex);

with:

throw SQLException("unilateral rollback of " + this, ex);

And that we wouldn't need to use Reflection in order to invoke
Connection.isValid().

Reply to this email directly or view it on GitHubhttps://github.com//issues/17#issuecomment-39184788
.

[rankinc]

OK, but the SQLExceptions and @OverRide annotations are fair game... ;-).

[lorban]

Yes, they are. FYI BTM was designed during the JDK 1.4 era, so quite a fair bit of its architectural design was done with those limitations in mind. Support for JDK 1.5+ constructs were added later on here and there but I don't think we ever did a complete code review to use all the new constructs. If you feel like reviewing them, feel free!

[rankinc]

Indeed, I think I saw a "migrate to JDK5 so that we can use Generics" commit somewhere... ;-)

[rankinc]

BTW, how did you obtain jdbc-3.0.jar please? That will obviously need updating to jdbc-4.0.jar for Java 6.

[rankinc]

It turns out that I don't need a complete jdbc-4.0.jar. All I really need (so far, anyway) is to recreate JDBC 4.0's CommonDataSource, Connection and Driver interfaces, because these are the main API differences between 4.0 and 4.1. Once overlaid on top of JDK7, then JDK7's native JDBC API turns back into 4.0.

This approach is far more likely to comply with BTM's Apache licence than downloading the complete 4.0 API from the Internet ;-).

[rankinc]

BTM now requires JDK6.