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

[Paul Sandoz]

I too have had problems with IntelliJ, not recognizing methods or autocompleting. I suspect we need to file a bug as the code arrangement is a little unusual.

Paul.

> On Dec 11, 2020, at 10:39 AM, Filip Krakowski <filip.krakowski at hhu.de> wrote:
> 
> 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
>>>> 
>>> 
>> 
>