Building with a new javac flag

[David Holmes]

On 15/11/2012 3:14 PM, Jonathan Gibbons wrote:
> I believe the plan would be to use pack200 to strip the attribute.

I don't know exactly what that means. Does it strip the attribute out of 
the existing class file, or does it create a copy without the attribute 
in it? Either way it means we need two copies of the .class files. If it 
could be stripped as part of the jarring process we'd only need a 
temporary copy of each file. There is about 160MB of .class files in a 
build.

David

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