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

[Filip Krakowski]

Hi,

sorry for all the mails. Turns out IntelliJ's autocompletion let me 
think the method was only accessible through "ucx_h$0". Importing it 
using "import static org.openucx.ucx_h.copysign;" works just fine. 
Switching to class mode again yields "Cannot resolve symbol 'copysign'". 
I think I will stick with source mode until IntelliJ is able to handle 
the generated class files.

Best regards
Filip

On 11.12.20 19:30, Filip Krakowski wrote:
> 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
>>>
>>
>