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

If you ever had a look at the Java EE specs for example, they always EXPLICITLY list the REQUIRED the APIs (not the
NON-REQUIREDones). It's never the case that the specs are listing dependencies in a negative way, but always in a
positiveway. Just like Maven would do, too, and just like there is no "excludes" clause restricting "import java.*" in
theJava language. :-) 

Anyways, it seems to be common sense among us that reflection SHOULD work, so my solution is not the right way to go.

Regarding your questions and just for couriosity, even being irrelevant due to the reflection topic meanwhile: My
examplealso fails even without (!) reflection once you remove the inner class and simply have the Java 8 method
implementeddirectly by the main class. Hence it proofs the special restriction for main classes. That restriction is
thedifference between 12.1 (= how an initial class is loaded) and 12.2 (= how other classes are loaded). It is an
optionalimplementation choice of the Oracle JVM to do so: It demands that ALL references from main class to other
classesMUST have existing byte code. This demand does not exists for classes NOT directly references but loaded lazily
ata later time (following 12.2 rules ONLY but not 12.1 rules). Just change my example and you'll see the effect - it
failsimmediately as soon as there is no wrapping inner class anymore decoupling the missing classes from the main
class.

-----Original Message-----
From: Vladimir Sitnikov [mailto:sitnikov.vladimir@gmail.com]
Sent: Donnerstag, 18. Juni 2015 00:07
To: Markus KARG
Cc: List
Subject: Re: [JDBC] Pre-processing during build

> Also AFAIK JDBC spec does not say reflection MUST be possible, does it?

Does the spec say anything on reflection might not being available?

I can easily imagine application that uses reflection, cglib, etc to
call/manage/pool connections, statements.
Can you list a couple of libraries that forbid reflection usage?

I think it is uncommon in java when a class that implements some
public API fails to "getMethods".

> Wrong. 12.1.1 contains more restriction on the initial class

Can you please cite that "restriction"?

> That is what you see in the difference of you initial example to mine on Gist. :-)

False. It was obvious from the start (see stacktrace) that it was
java.lang.Class.privateGetDeclaredMethods that failed.
If the restriction exists indeed, another example is required to
highlight that. My examples are doomed to die of reflection.

Vladimir