[foreign] RFR 8217369: jextract macro parser could avoid javac for simple macros

[Maurizio Cimadamore]

On 18/01/2019 11:19, Sundararajan Athijegannathan wrote:
> Hi,
>
> Yes, Integer.decode throws NumberFormatException if number won't fit 
> as int - and the jextract control will fall back to use javac. BTW, 
> even javac approach would require user to use "L" suffix (for larger 
> int that won't fit as int), right?

Sure, long constants need L suffix. Ok, I was more checking that we did 
not truncate the value as an Integer.

I'm happy with the change, and it's relatively harmless - so let's try 
it out.

Maurizio


>
> -Sundar
>
> On 18/01/19, 4:39 PM, Maurizio Cimadamore wrote:
>> Hi Sundar,
>> the patch looks good - I'm not super super that splitting the code in 
>> this way is worth - in the sense that having a unique path to process 
>> macro seems generally more regular and less error prone (albeit more 
>> inefficient).
>>
>> Also, I believe there could be some differences with respect to the 
>> old behavior - for instance, what happens if a number doesn't fit 
>> into an Integer? The javac-based approach will return a long, not 
>> sure what will happen in this case - likely the decode() method will 
>> throw and you will fall back to use javac again. But I thought it was 
>> worth asking.
>>
>> Maurizio
>>
>> On 18/01/2019 08:46, Sundararajan Athijegannathan wrote:
>>> Please review.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217369
>>> Webrev: https://cr.openjdk.java.net/~sundar/8217369/webrev.00/
>>>
>>> 3 to 4s improvement on Python sample (13s to 9/10s on Mac). About 
>>> 45% are simple int valued macros.
>>>
>>> Thanks,
>>> -Sundar