Building with a new javac flag

[Alex Buckley]

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