From: | "Markus KARG" <markus(at)headcrashing(dot)eu> |
---|---|
To: | <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: Pre-processing during build |
Date: | 2015-06-15 21:59:45 |
Message-ID: | 000c01d0a7b6$97571ee0$c6055ca0$@eu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Stephen,
thank you for starting this thread.
If it would be up to me, I would try to get rid of pre-processing if any
possible, since it is a real p.i.t.a., as long as we can find a different
solution to provide the same number of supported JDKs and JDBC versions.
The question is: How? Possibly by simply using "JRE8-JDBC42.jar" ALWAYS?
Has anybody tried whether it is possible to simply load a JRE8-JDBC42.jar on
JRE6? I mean, not to actually invoke the new JDBC42 APIs, just to load the
JAR and invoke the JDBC3 APIs only for example. The APIs themselved are
backwards compatible, and as long as we don't invoke the new APIs, no
ClassNotFound should happen (AFAIK the JRE loads classes only at first
actual instantiation, but not simply because it is contained in a loaded
.class file as a parameter). I mean, as long as we do not use JRE8-only APIs
inside the Driver, and as long as we don't write the .class files in JRE8
byte code, certainly.
Or did I miss something in this theoretical approach?
Regards
-Markus
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2015-06-15 22:17:14 | Re: Pre-processing during build |
Previous Message | Stephen Nelson | 2015-06-14 20:37:54 | Pre-processing during build |