Building with a new javac flag

[Erik Joelsson]

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.