Building with a new javac flag

[Alex Buckley]

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
>