@GenerateNativeHeader

[Alan Bateman]

I think we need to discuss this one. It adds further compile-time 
dependencies on the jdk.compiler module. On the surface it is harmless, 
from another angle is anti-modules and also brings up the topic of 
dependencies that have scope. My primary concern is that we haven't 
worked out all the details on the bootstrapping of new build and so 
additional dependencies from the base module may be problematic. Note 
that there is already one compile time dependency on this annotation (in 
sun.nio.ch.IOStatus) but that one is trivially removed.

-Alan

-------- Original Message --------
Subject: 	Need reviewer - @GenerateNativeHeader
Date: 	Tue, 22 May 2012 18:14:54 -0700
From: 	Kelly O'Hair <kelly.ohair at oracle.com>
To: 	build-dev at openjdk.java.net build-dev <build-dev at openjdk.java.net>



7170969: Add @GenerateNativeHeader to classes whose fields need to be exported for JNI
http://cr.openjdk.java.net/~ohair/openjdk8/generateHeaders1/webrev/

The new build infrastructure wants to fully automate the generation of the JNI header files (running javah).
On classes that have "native" methods this is obvious, but class that only export constants, and whose constants
are needed in the JNI native code, we need to mark these classes as needing their native header file generated.

This change is adding:

import javax.tools.annotation.GenerateNativeHeader;

/* No native methods here, but the constants are needed in the supporting JNI code */
@GenerateNativeHeader

To any class without a native method, but needing to expose it's constants to the native code.

-kto