RFR: 8009428 and 8009429 - Profile related fixes and clean ups (original) (raw)

David Holmes david.holmes at oracle.com
Thu Mar 14 05:36:19 UTC 2013

Hi Alan,

On 12/03/2013 8:05 PM, Alan Bateman wrote:

On 12/03/2013 07:10, David Holmes wrote:

:

For the intro comment in profile-rtjar-includes.txt then it might be useful to beef up the comment to explain what happens when an API package does not match one of the rules, ie: does it go into compact1, only the full JRE, or none. Also make it explicit that the form DialogCallbackHandler*.class should not be used. I suggest this for the benefit of someone needing to tweak this in the future. I have updated the webrev with additional commentary. Thanks, that will be very useful to future maintainers.

I have played with com.sun.tools.javac.sym.Profiles and so the changes to MakefileProfiles look okay to me but Jon should really be the reviewer for this. One thing about maxProfiles is that it should match Profile.values.length maybe maxProfiles should not be hardcoded to 4. Sorry but what is Profiles.values.length? Previously we inferred the number of profiles from the fact that we failed to find PROFILEn for some value n. That can't work (easily) now hence the hard limit. I meant com.sun.tools.javac.jvm.Profile, it's an enum of the profiles so it means that the knowledge about 3 + full JRE is now in two places.

I decided not to do this because it turns out that "4" is hardwired within the internal debugging code of this class anyway. I'll file a RFE to clean this up in conjunction with the additional testing you mention below.

Thanks, David

Another thing is whether to add a test or beef up an existing test (ProfileOptionTest.java in particular). What exactly is it that you would like to test for? I think the test should include a few cases to cover a few selected types in sub-packages to make sure they are in the right profile. -Alan.

More information about the core-libs-dev mailing list