Building with a new javac flag

[Kelly O'Hair]

Sorry, since I haven't been involved in the discussions, I was just trying to gain some understanding
of when this data is needed, and if we could just simplify things and generate it all the time.

The configure&&make style of building opens quite a few doors in terms of build variations, and
that comes with positives and negatives. So I look for places where things can just be defaulted to 'on all the time'
with a rarely/selectively used 'turn it off' setting.  At least that is my preference.

-kto

On Nov 13, 2012, at 3:16 PM, Alex Buckley wrote:

> An IDE is not trying to debug code in rt.jar; it's trying to build a directory of classes and methods therein for type-ahead and refactoring. Quoting Brian:
> 
> "For the JDK, exposing this information means that IDEs can harvest parameter information without parsing sources, which is used for "implement methods" code wizards.  (Compare what happens in IntelliJ when you implement a method from a JDK interface to what happens in Eclipse.  In IJ, you get the names from the source; in Eclipse, you get "foo(String s1, String s2, int i1)".)"
> 
> We don't want javac to generate parameter names all the time for reasons outlined in the spec PDF posted to the enhanced-metadata-spec-discuss list. Again, I am trying to keep policy decisions about the feature off build-infra-dev.
> 
> Alex
> 
> On 11/13/2012 3:11 PM, Kelly O'Hair wrote:
>> From an IDE perspective, does it make sense to have parameter names,
>> but not line numbers? Seems like if we just generate the parameter
>> names all the time, and have pack200 strip them out for the JRE, then
>> we could just generate them all the time. Then there is no need for
>> an option, just a change to pack200 to remove a few attributes when
>> it is told to delete debug information in the jre runtime jars?
>> 
>> -kto
>> 
>> On Nov 13, 2012, at 12:50 PM, Alex Buckley wrote:
>> 
>>> On 11/13/2012 4:00 AM, Alan Bateman wrote:
>>>> This one may be significant enough to me to justify a configure
>>>> option. On the other hand, "make images profiles" would mean all
>>>> the resulting images (JDK, JRE, and Compact Profiles) would
>>>> either all have/not the parameter names.
>>> 
>>> 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".
>>> 
>>> Where should we look at the new build, given that the parameter
>>> feature lives in the jdk8/tl forest?
>>> 
>>> Alex
>>