Re: Pre-processing during build

Поиск
Список
Период
Сортировка
От Dave Cramer
Тема Re: Pre-processing during build
Дата
Msg-id CADK3HHK9TUug9amtabv1a+27u_bb31FCsLBarWsPv_PD12JCcw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Pre-processing during build  ("Markus KARG" <markus@headcrashing.eu>)
Ответы Re: Pre-processing during build  (Sehrope Sarkuni <sehrope@jackdb.com>)
Re: Pre-processing during build  (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>)
Re: Pre-processing during build  ("Markus KARG" <markus@headcrashing.eu>)
Список pgsql-jdbc
How can you use the same name and different bytecode versions ?

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On 15 June 2015 at 17:59, Markus KARG <markus@headcrashing.eu> wrote:

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


В списке pgsql-jdbc по дате отправления:

Предыдущее
От: "Markus KARG"
Дата:
Сообщение: Re: Pre-processing during build
Следующее
От: Sehrope Sarkuni
Дата:
Сообщение: Re: Pre-processing during build