Re: Pre-processing during build - Mailing list pgsql-jdbc

I see nothing wrong with implementing Driver using java.reflect.Proxy, and if we want to be paranoid about classloading, using reflection (within the implementation of the Proxy-based Driver) to instantiate and invoke methods on a version-specific implementation of Driver.  That way, even when using reflection, discovering an "unresolvable future type" is just impossible.  The Proxy-based Driver would delegate to some PGDriver6 / PGDriver7 / PGDriver8 which could be compiled in steps (as I described in an earlier message on this thread) and not to some PGSuperDriver, where PGDriver8 extends PGDriver7, and PGDriver7 extends PGDriver6, and where PGDriver8 returns (from the "connect" method) a PGConnection8 (extending PGConnection7), PGDriver7 returns PGConnection7, and so on.  So, even using reflection, it would be impossible to work with mismatched versions; the only exception being (for example in Java6 code) doing an explicit Class.forName("PGDriver8") but that sort of code just isn't possible except when the client is incompetent or malicious.  And, as I suggested in my previous message, it requires no code generation, just an extra compilation step per supported version.

As a side note, about the discussion on interpretations of the JLS, I've not yet encountered any JVM that attempts to fully-resolve all signatures as soon as it loads a class.  Does such a JVM exist?  I would assume that it would have poor performance for classloading (and a high memory overhead for class metadata, such as permgen/metaspace usage) because it would need to be recursive (for each type discovered in a method signature or body, it would need to load that type and all of its referenced types, recursively).  I'd be very interested to know how it deals with circular references (for example A refers to B and vice-versa ; it can't resolve A before B, and vice-versa), such as Object.toString() because String can't be loaded before Object, but Object would need to resolve String.

Getting back to the original discussion, I'm neutral on the Ant vs Maven debate, but it I'm sure that driver developers would benefit (readability and reliability) from plain old source code, simple class extending and step-by-step compilation to handle API evolution without trying relying on JVM behavior to have an all-in-one single implementation that may contain more than is advertised by specific interface versions.  This approach should also keep the build process deterministic and relatively straightforward and be able to produce a single driver artifact compatible with all JDBC versions, with no burden on driver users.