Re: Pre-processing during build

From: Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>
To: Mark Rotteveel <mark(at)lawinegevaar(dot)nl>, Dave Cramer <pg(at)fastcrypt(dot)com>
Cc: List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Pre-processing during build
Date: 2015-11-05 18:33:53
Message-ID: CAB=Je-HjcTa6_=1YiJ0T21Vj7S9Jc2W3_2jA5DJ=2O_TLdso1Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Dave Cramer 2015-11-05 19:58:26 Re: Pre-processing during build
Previous Message Victor Wagner 2015-11-05 15:12:35 Re: Patch: Implement failover on libpq connect level.