"#define" constants as methods

[Jorn Vernee]

Hello,

For string constants we have to allocate and copy memory, so we defer 
the initialization of those. For that to work, at least string constants 
need to be exposed as methods. Historically we had a different 
translation strategy for constants that also required them to be exposed 
as methods, and I think we kept the methods for all types of constants 
mostly out of consistency.

 > This seems to be cumbersome, especially if they are error codes like 
in my case and I want to use them in a switch statement.

This is a good point. The result of a method call can not be used as a 
case label in a switch. We could potentially change jextract to just 
expose string constants using methods, and use fields for the others. 
This would be inconsistent, but I think better, since it allows 
constants to be used as switch case labels. I suspect Maurizio will want 
to weigh in on this as well.

 > How will the tool be finally published? Will it become part of the JDK?

At least for the foreseeable future it will be kept as a separate tool, 
and published through jdk.java.net

Jorn

On 04/04/2024 16:00, Klaus Malorny wrote:
>
> Hi,
>
> I have two projects which currently use JNI and which need to be 
> migrated eventually, so I started playing around with Java 22's 
> foreign package and the jextract code generator (Build 
> 22-jextract+3-13). What puzzles me so far is the fact that constants 
> are generated as methods (which actually use static private member 
> variables with the same name). This seems to be cumbersome, especially 
> if they are error codes like in my case and I want to use them in a 
> switch statement. Maybe there is a reasoning behind it, but I can't 
> imagine it ;-)
>
> Besides this, another (dumb) question: How will the tool be finally 
> published? Will it become part of the JDK?
>
> Regards,
> Klaus
>