Christopher BROWN wrote:
> Then, merge all JARs into a single JAR. Clients could then refer to the
> specific driver version they require in code, or use a generic Driver class that
> (in the constructor) detects the appropriate JDBC version and fixes a "final"
> int or Enum field, used thereafter in "switch" blocks to call the appropriate
> driver version, acting as a lightweight proxy when the specific driver version
> can't be referred to (for backwards compatibility). More adventurous developers
> ..........................................
Somehow as someone who manages a generic database access tool I don't like the
sounds of this requirement. Why as a client developer should I have to detect
the appropriate Java Version then somehow figure out the user's requirement
for the Driver class to call in your JDBC? I don't have to do this for any other
database so why for PostgreSQL's JDBC.
It may be of no concern really, but that is going to require me to change
the coding in my client for instantiating your Driver class, which is the
same for all databases so far, all so that you can change your build process,
which does not appear to be broken.
How about backup and state the one, two, three pros, and cons for initiating
the change in the build process again. Then highlight what additional work
would be required in the code, etc. to accomplish the new build process. Then
the list could input on the proposal. Maybe that has already taken place and
I missed it?
danap.
> ~
> ~
> ~
> ~
> ~
> Hope that helps ; hope it's not redundant with regards to messages sent since I
> started typing away my 2 cents... In any case, I regularly use these techniques
> in production code with no accidents.
>
> --
> Christopher
