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

[Sundararajan Athijegannathan]

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?

-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