Re: Pre-processing during build

If you ever had a look at the Java EE specs for example, they always EXPLICITLY list the REQUIRED the APIs (not the NON-REQUIRED ones). It's never the case that the specs are listing dependencies in a negative way, but always in a positive way. Just like Maven would do, too, and just like there is no "excludes" clause restricting "import java.*" in the Java 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 example also fails even without (!) reflection once you remove the inner class and simply have the Java 8 method implemented directly by the main class. Hence it proofs the special restriction for main classes. That restriction is the difference between 12.1 (= how an initial class is loaded) and 12.2 (= how other classes are loaded). It is an optional implementation choice of the Oracle JVM to do so: It demands that ALL references from main class to other classes MUST have existing byte code. This demand does not exists for classes NOT directly references but loaded lazily at a later time (following 12.2 rules ONLY but not 12.1 rules). Just change my example and you'll see the effect - it fails immediately 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(dot)vladimir(at)gmail(dot)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