Re: Pre-processing during build
От | Vladimir Sitnikov |
---|---|
Тема | Re: Pre-processing during build |
Дата | |
Msg-id | CAB=Je-HjcTa6_=1YiJ0T21Vj7S9Jc2W3_2jA5DJ=2O_TLdso1Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Pre-processing during build (Mark Rotteveel <mark@lawinegevaar.nl>) |
Ответы |
Re: Pre-processing during build
|
Список | pgsql-jdbc |
I have one more question: what if we use true "pre-processing" during build? (e.g. https://github.com/raydac/java-comment-preprocessor) The suggestion is as follows: 1) "AbstractStatement implements java.sql.Statement" 2) JDK8 is used for development 3) During build, AbstractStatement code is pre-processed as per "current jdk" (e.g. if compiling under java6, then java7 and java8 would be skipped out) The only problem was we could not spell literally "AbstractStatement implements java.sql.Statement" as different JDK versions have different number of methods. Using a pre-procesor solves that out. It would eliminate current jdbc3, jdbc3g, jdbc4, ... stuff. It will make sane class hierarchies possible as well. Currently we cannot have AbstractPreparedStatement extends AbstractStatement since we have multiple different AbstractJdbc2Statement and AbstractJdbc3Statement. From my point of view "jdbcXX" packages serve no good except allowing multiple-jre support. I think having a single "AbstractStatement implements java.sql.Statement" would be a huge win in terms of ease of development. Vladimir
В списке pgsql-jdbc по дате отправления: