While I can imagine a Java PostgreSQL driver that would use the libpq syntax, I can't see it being able to have any useful sort of half-compatibility with JDBC, whether it mimics its interfaces or not. I'm not sure it would be very useful at all, considering how much the existing tooling the the Java world relies on JDBC.
I won't claim to have studied this in great detail but there is a lot more to the JDBC spec beyond the semantics of "PreparedStatement.parse(String)". No need to throw out the baby with the bath water and reinvent ResultSet, Connection and various other interfaces that are perfectly usable before and after a suitable query has been fully parsed.
When I say "setInteger(1, new Integer(1000))" I don't care whether I had to write "SELECT ? AS int_val" OR "SELECT $1 AS int_val"; though the later has the nice property of providing corresponding numbers so that I would write something like "SELECT $1 AS int_val, $1 AS int_val_2" and not be forced to write "setInteger(2, new Integer(1000))" to pass in a value to the second - but identical - parameter. Maybe it violates the semantics defined by the API - which I could be making too lightly of - but having the same mechanics involved to solve the same problem - with only minor semantic nuances to remember seems within the realm of reasonable.
Yes, you're probably right. Nevertheless, I'm not sure why anyone would switch to that format, knowing that other tools that are on top of JDBC would certainly not work very well (e.g. Groovy SQL, JOOQ, or ORMs like Hibernate, ...).
Hadn't really pondered those :( though to be honest a compatibility layer to write out sequential $# instead of ? doesn't seem that difficult - but it would depend on the codebase of the tool. Unfortunately the driver wouldn't be in a position to do the work.