Kevin Wooten <kdubb@me.com> wrote:
> > On Nov 4, 2014, at 12:55 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
> >
> > I have to say I like some aspects of how pgjdbc-ng is being done - in
> > particular use of Maven and being built around non-blocking I/O.
> >
> > OTOH, the use of Google Guava I find pretty inexplicable in a JDBC
> > driver, and since it hard-depends on JDK 7 I don't understand why Netty
> > was used instead of the async / non-blocking features of the core JVM.
> > That may simply be my inexperience with writing non-blocking socket I/O
> > code on Java though.
> >
Java6 has been EOL since 2011 and Java7 is EOL in less than 6 months. I think
that depending on old Java 7 version that soon should not even be used in
production (without paying for extra support) can hardly be too hard requirement.
> It confuses me as to why you consider using stable, well implemented, well tested and well cared for libraries as
inexplicable. > Just because we are building a “driver” means we have to write every line of code ourselves? No
thanks.
Embedding parts of other projects into code-base during build with renamed packages is nowadays common practice in java
projects:spring does it, elasticsearch embeds whole netty and more, even jre embeds for example xerces and asm.
It might not be the optimal solution, but still definitely better than writing everything from scratch or copy-pasting
codefrom other projects.
If pgjdbc-ng provides both a thin maven version (with external versioned dependencies) and a fat-jar with the external
versionsrepackaged inside the users can choose either old way: just-drop-a-jdbc-jar-into-project or new way with their
chosenbuild tool that automatically manages the dependencies.
-Mikko