Review request on the optional modules support

[Jesse Glick]

On 08/08/2011 08:33 PM, Mandy Chung wrote:
>> ...should Class and Package be in java.lang.reflect...
>
> I too wonder about the inconsistency.

Do you have any ambition to make java.lang.reflect be an optional module? (This would require Object.getClass() to throw ModuleNotPresentException.) There are two reasons 
this might be useful:

1. Secure containers (sandboxes) may prefer that hosted code not even run those limited reflective calls that the security manager would permit.

2. Compilers or analyzers could make more aggressive optimizations or error checks knowing that reflection is unavailable in a given codebase.

A third use case would be for a runtime subset that would permit pure functions to be written - i.e. those guaranteed by form to return consistent results - but this 
would require isolating other parts of java.lang as well: Thread/ThreadGroup, System, Runtime, most Object methods, etc. It may be impossible to do this without vetting 
bytecode manually.

On a related note - I have an RFE open about @SupportedAnnotationTypes in which one suggested fix is for X.class.getCanonicalName() and similar constructs to be treated 
as compile-time constants. It would be odd but I suppose harmless for the definition of CTCs to refer to modules other than java.lang.

> The compiler can't detect [such potential verification errors]

Seems like this is more the domain of FindBugs.