Building with a new javac flag

[Alex Buckley]

The pack200 tool knows that some attributes, e.g. LocalVariableTable, 
are deemed by the JVM Spec to exist for debugging purposes. 
--strip-debug will remove them. To remove a new non-debug attribute 
like MethodParameters, the invocation is:

pack200 --method-attribute=MethodParameters=strip -r rt.jar

(This will repack an existing jar, but I'll take up that point with 
David elsewhere in the thread.)

Alex

On Wednesday, November 14, 2012 11:39:01 AM, Jonathan Gibbons wrote:
> OK, but it still sounds like the policy of when to include the
> parameters can be determined without requiring extra configuration
> parameters.
>
> (Which is separate from whether we should have parameters to override
> the default determination.)
>
> -- Jon
>
>
> On 11/14/2012 11:35 AM, Alex Buckley wrote:
>> It sounds like the jdk-variant option would perfectly dominate the
>> enable-parameters option, if we wanted parameters in the normal
>> variant's JDK image and the normal variant's JRE image and the normal
>> variant's Compact Profiles image.
>>
>> But we would like parameters in only the normal variant's JDK image,
>> not the other images, because IDEs only run on the biggest fattest JDK.
>>
>> Alex
>>
>> On 11/14/2012 10:21 AM, Jonathan Gibbons wrote:
>>> If we already have a configure option for "JDK variant (normal or
>>> embedded)",  why do we need any additional options for parameter names,
>>> if the decision whether or not to use parameter names is a function of
>>> the variant?
>>>
>>> -- Jon
>>>
>>>
>>>
>>> On 11/14/2012 09:09 AM, Kelly O'Hair wrote:
>>>> Seems like if we want this information a permanent aspect of certain
>>>> builds, it needs a configure argument means of doing it.
>>>>
>>>> That doesn't prevent the use of JAVAC_FLAGS for this or other things.
>>>>
>>>> ---
>>>> I'm getting concerned that we end up with too many variations here,
>>>> for the typical developers they need simple
>>>> ways to get the standard configurations.
>>>>
>>>> -kto
>>>>
>>>> On Nov 14, 2012, at 1:43 AM, Erik Joelsson wrote:
>>>>
>>>>> Alan and David are correct regarding how the build currently works.
>>>>> To support the case of only providing this information in certain
>>>>> images or profiles (like the JDK but not the JRE) we would need to
>>>>> produce class files of both kinds at some point in the build. This
>>>>> could be accomplished either by compiling everything twice or by
>>>>> stripping out the information at some point.
>>>>>
>>>>> If the case is just to have different defaults between embedded and
>>>>> normal, it should be rather straight forward to add a configure
>>>>> argument that adds to the JAVAC_FLAGS variable. I would suggest
>>>>> adding this somewhere in common/autoconf/toolchain.m4. If you just
>>>>> want to see the effects of adding this parameter on a single build,
>>>>> running "make JAVAC_FLAGS=-parameter" should do the trick.
>>>>>
>>>>> /Erik
>>>>>
>>>>> On 2012-11-14 07:13, David Holmes wrote:
>>>>>> Alan is correct. A configuration is a selection of a range of things
>>>>>> including platform, JDK variant (normal or embedded), JVM variant
>>>>>> (client, server, minimal), "release" (product or fastdebug). When
>>>>>> you do a build the classes only get compiled once regardless of
>>>>>> which jar they end up in, or which image the jar ends up in. So this
>>>>>> javac option will be applied to all classes and hence to all build
>>>>>> artifacts.
>>>>>>
>>>>>> None of which forces the selection of this being a configure time
>>>>>> option versus a "make" time option. The main issue with the latter
>>>>>> is that it makes it easier to produce inconsistent build results if
>>>>>> you do partial builds and change the value of the option each time.
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On 14/11/2012 7:45 AM, Alan Bateman wrote:
>>>>>>> On 13/11/2012 20:50, Alex Buckley wrote:
>>>>>>>> The primary reason for storing parameter names in JDK8 class
>>>>>>>> files is
>>>>>>>> to help IDE vendors, so it's fine if only the JDK image has
>>>>>>>> them. We
>>>>>>>> are not making a general promise that any program will be able to
>>>>>>>> find
>>>>>>>> parameter names of core Java Java SE classes at runtime. (Again,
>>>>>>>> please set aside concerns about footprint, compatibility, etc
>>>>>>>> on this
>>>>>>>> list.)
>>>>>>>>
>>>>>>>> It sounds like a ./configure option of --enable-parameters
>>>>>>>> could add
>>>>>>>> an option to JAVAC_FLAGS - you say it would affect all images? But
>>>>>>>> Erik said "the value of the option has different defaults
>>>>>>>> depending on
>>>>>>>> jdk variant/profile".
>>>>>>> Suppose we do "configure --enable-paramater-names && make" then
>>>>>>> this
>>>>>>> would compile the classes and native libraries but at this point we
>>>>>>> don't have any images, rather it's just raw classes on the file
>>>>>>> system
>>>>>>> (no rt.jar).
>>>>>>>
>>>>>>> A subsequent "make images" would create the j2sdk-image and
>>>>>>> j2re-image
>>>>>>> with the rt.jar and the layout that we are used to. I think, and
>>>>>>> Erik or
>>>>>>> David can correct me, is that the same class files end up in both
>>>>>>> images. Subsequent stripping of debug attributes from everything in
>>>>>>> rt.jar may happen later, at least where JRE download size is
>>>>>>> important.
>>>>>>>
>>>>>>> So my point about the parameter names is that the same classes are
>>>>>>> used
>>>>>>> for all images. The "profiles" build is like "images", it's really
>>>>>>> just
>>>>>>> packaging up the already compiled bits and so would get the same
>>>>>>> class
>>>>>>> files, assuming of course that the JDK/JRE images and profiles
>>>>>>> images
>>>>>>> are coming from the same build.
>>>>>>>
>>>>>>> When Erik used the term "variant" then I assume he meant the
>>>>>>> --with-jdk-variant and --with-jvm-variant options to configure
>>>>>>> normal or
>>>>>>> embedded, client or server VM and things like that. That's part
>>>>>>> of the
>>>>>>> configuration. If we are compiling classes differently then I
>>>>>>> suspect it
>>>>>>> may require a separate configuration.
>>>>>>>
>>>>>>>> Where should we look at the new build, given that the parameter
>>>>>>>> feature lives in the jdk8/tl forest?
>>>>>>> common/makefiles in the top-level repo, and makefiles directory in
>>>>>>> each
>>>>>>> of the other repos. Alternatively this guide:
>>>>>>>
>>>>>>> http://openjdk.java.net/projects/build-infra/guide.html
>>>>>>>
>>>>>>> -Alan.
>>>
>