[foreign-jextract] Using many headers splits generated code in package-private classes

[Filip Krakowski]

Hi,

just tried it out using source mode. Here I also get source files with 
numbered suffixes (e.g "ucx_h$1.java", "ucx_h$2.java") in which the 
classes are declared package-private. These classes contain public 
static methods which I therefore cannot access.

    /class ucx_h$0 {//
    //
    //    /* package-private */ ucx_h$0() {}//
    //    public static  MethodHandle copysign$MH() {//
    //        return ucx_h$constants$1.copysign$MH();//
    //    }//
    //    public static @C("double") double copysign (@C("double")
    double __x, @C("double") double __y) {//
    //        try {//
    //            return
    (double)ucx_h$constants$1.copysign$MH().invokeExact(__x, __y);//
    //        } catch (Throwable ex) {//
    //            throw new AssertionError(ex);//
    //        }//
    //    }/


Here "ucx_h$0" is package-private which makes the public static method 
"copysign" inaccessible. Shouldn't these classes be public?

Best regards
Filip

On 11.12.20 18:59, Filip Krakowski wrote:
> Hi,
>
> I should add that this only happens when a method gets placed inside a 
> inner class (e.g "ucx_h$1").
>
> Best regards
> Filip
>
> On 11.12.20 18:56, Filip Krakowski wrote:
>> Hi,
>>
>> In my case autocompletion doesn't work either and IntelliJ only shows 
>> the message "Cannot not resolve symbol 'eventfd'" when I try to 
>> import it using "import static org.openucx.ucx_h.eventfd;". However, 
>> compiling and executing a small class calling the function works.
>>
>> Best regards
>> Filip
>>
>> On 11.12.20 18:47, Maurizio Cimadamore wrote:
>>> The class generation mode has always had issues for me in IntelliJ. 
>>> Last time I checked, Intellij did not handle the ldc opcode with 
>>> dynamic constants (condy) internally, which gave issues when e.g. 
>>> trying to decompile a class.
>>>
>>> That said, auto completion at least used to work.
>>>
>>> Maurizio
>>>
>>> On 11/12/2020 17:41, Filip Krakowski wrote:
>>>> Hi,
>>>>
>>>> looks like I wrote too soon and IntelliJ simply is not able to 
>>>> handle the generated class files correctly. Is anyone using 
>>>> IntelliJ (2020.3) and can confirm that it is not able to resolve 
>>>> generated methods which are created in inner classes? This worked 
>>>> for me in the past.
>>>>
>>>> Best regards
>>>> Filip
>>>>
>>>> On 11.12.20 18:30, Filip Krakowski wrote:
>>>>> Hi,
>>>>>
>>>>> I am trying to generate bindings for the ucx library 
>>>>> (https://github.com/openucx/ucx). The input I pass to jextract is 
>>>>> the following header file (filename = "ucx.h", package = 
>>>>> "org.openucx", source mode = false).
>>>>>
>>>>>     /// OpenUCX Transports//
>>>>>     //#include <uct/api/uct.h>//
>>>>>     //
>>>>>     //// OpenUCX Protocols//
>>>>>     //#include <ucp/api/ucp.h>//
>>>>>     //
>>>>>     //// I/O Multiplexing//
>>>>>     //#include <sys/epoll.h>//
>>>>>     //#include <sys/eventfd.h>//
>>>>>     //
>>>>>     //// File descriptor utilities//
>>>>>     //#include <fcntl.h>//
>>>>>     //#include <unistd.h>/
>>>>>
>>>>> It looks like a large amount of the generated code ends up in 
>>>>> numbered package-private classes. As an example, I can't access 
>>>>> the MethodHandle for "eventfd" because it is in a package-private 
>>>>> class named "org.openucx.ucx_h$1". If I remove the includes for 
>>>>> "<uct/api/uct.h>" and "<ucp/api/ucp.h>" the generated method is 
>>>>> created in class "org.openucx.ucx_h" where I can access it./
>>>>> //
>>>>> /Is there a way to access code generated in the other (numbered) 
>>>>> package-private classes I'm missing?
>>>>>
>>>>> Best regards
>>>>> Filip
>>
>