RFR: 8009428 and 8009429 - Profile related fixes and clean ups
david.holmes at oracle.com
Thu Mar 14 05:36:19 UTC 2013
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 PROFILE_n 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
>>> 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.
More information about the core-libs-dev