RFR: 8009428 and 8009429 - Profile related fixes and clean ups
    David Holmes 
    david.holmes at oracle.com
       
    Fri Mar  8 01:48:35 UTC 2013
    
    
  
Not sure which is best list for this given Alan will likely be the only 
reviewer anyway :)
Webrevs under:
http://cr.openjdk.java.net/~dholmes/8009428_8009429/
Two related sets of fixes here:
JDK-8009428: Revert changes to $ substitution performed as part of 
nashorn integration
This removes the special $ handling in ListPathSafely in MakeBase.gmk; 
and reverts the change in file names in CreateJars.gmk so that \$$ is 
restored to \$$$$
---
JDK-8009429 Miscellaneous profiles cleanup
Miscellaneous cleanups to the Profiles.gmk file and the include lists:
- ensure all lists are expanded in case they contain wildcards
Previously I only expanded lists I knew to be (or have been non-empty).
- use wildcards to list related classes
Avoid listing explicit classes, particularly if nested classes are involved.
- remove redundant subpackage entries if all subpackages are in the same 
profile
The original list was generated from a list of all packages and 
subpackages and contained a lot of redundancy. If profile_1 for example 
contains java/lang then it implicitly contains java/lang/ref, 
java/lang/reflect etc, and doesn't need them listed. If a particular 
subpackage is not part of profile_1, say java/lang/special is in the 
full JRE only, then we need only list java/lang/special as an included 
package for the full JRE. All included packages for the full JRE and 
higher numbered profiles become excluded packages for the lower numbered 
profiles hence profile_1 would be "everything in java/lang except 
java/lang/special".
(Things are a little more complicated when the subpackage exists in the 
lower numbered profiles. In that case the higher-level has to list out 
the included subpackages explicitly together with included classes.)
- rename things so that the full JRE is not referred to as "PROFILE_4"
The Full JRE is not a compact profile. While we logically treated it as 
a fourth profile for build purposes this is potentially confusing and so 
we no longer do that. A JRE may be a full JRE or it may be a Compact 
Profile JRE.
Plus in CreateJars.gmk:
- cleanup the de-beaning actions
Now we've got a better understanding of the way $ gets processed I 
figured out how to express this the "natural" way.
---
Thanks,
David
    
    
More information about the build-dev
mailing list