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 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
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.
