Building with a new javac flag

[Jonathan Gibbons]

I believe the plan would be to use pack200 to strip the attribute.

-- Jon

On 11/14/2012 09:12 PM, David Holmes wrote:
> On 15/11/2012 6:07 AM, Alex Buckley wrote:
>> Yes. We want parameters when jdk-variant=normal, so we'll include
>> -parameters in the JAVAC_FLAGS for that configure option/value combo.
>> Then the make targets for 'images' and 'profiles' will invoke pack200 to
>> strip the parameter attributes except for the j2sdk-image.
>
> In that case we don't need any new configure options as this approach 
> also works for embedded as it doesn't care about the full JDK.
>
> Though we might want to conditionalize this on whether OPENJDK is true 
> or not. There are some concerns about Oracle JDK build requirements 
> being applied by default to OpenJDK builds.
>
> Also how does the stripping work - does it mean that we will have to 
> copy all the .class files first, or can it be applied when creating 
> the jar files?
>
> David
>
>> Eric McCorkle will have a javac capable of emitting the attribute this
>> week, so we'll try it out on his local forest.
>>
>> Alex
>>
>> On 11/14/2012 11:39 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.
>>>>>
>>>