Pointer/Scope API questions
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Wed Jan 8 15:14:07 UTC 2020
On 08/01/2020 12:34, Ty Young wrote:
>
> On 1/8/20 6:23 AM, Maurizio Cimadamore wrote:
>>
>> On 08/01/2020 12:12, Ty Young wrote:
>>>
>>> On 1/8/20 5:53 AM, Maurizio Cimadamore wrote:
>>>>
>>>> On 08/01/2020 11:48, Ty Young wrote:
>>>>>
>>>>> On 1/8/20 5:43 AM, Maurizio Cimadamore wrote:
>>>>>>
>>>>>> On 08/01/2020 11:38, Ty Young wrote:
>>>>>>>
>>>>>>> On 1/8/20 5:09 AM, sundararajan.athijegannathan at oracle.com wrote:
>>>>>>>> [...]
>>>>>>>>>>>
>>>>>>>>>> Are you also adding `--add-modules
>>>>>>>>>> jdk.incubator.foreign,jdk.incubator.jextract` when running? I
>>>>>>>>>> was seeing a similar error when I forgot to do that.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ah, no. Works now.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Is it supposed to throw an exception there though? The modules
>>>>>>>>> are apart of the JDK and preview features are enabled so I
>>>>>>>>> don't understand why the extra step of adding the modules at
>>>>>>>>> runtime is being required here. Is it a bug?
>>>>>>>>
>>>>>>>> No. It is not a bug. You've to explicitly add "incubator"
>>>>>>>> modules for compilation as well as for runtime.
>>>>>>>
>>>>>>>
>>>>>>> TIL.
>>>>>>>
>>>>>>>
>>>>>>> Just noticed though that while the Memory Access API works, the
>>>>>>> jextract API fails because of javax.tools's JaveFileObject from
>>>>>>> the java.compiler module.
>>>>>>>
>>>>>>>
>>>>>>> My compiler/runtime --add-modules argument looks like:
>>>>>>>
>>>>>>>
>>>>>>> --add-modules
>>>>>>> jdk.incubator.foreign,jdk.incubator.jextract,java.compiler
>>>>>>>
>>>>>>>
>>>>>>> It is also required in module-info.java. Am I missing something
>>>>>>> here?
>>>>>>
>>>>>> Uhm - java.compiler should be available w/o extra flags... what
>>>>>> code are you trying to run?
>>>>>
>>>>>
>>>>> Code:
>>>>>
>>>>>
>>>>> Path header =
>>>>> Path.of("/opt/cuda/targets/x86_64-linux/include/nvml.h");
>>>>>
>>>>> JextractTask task = JextractTask.newTask(true, header);
>>>>>
>>>>> task.write(Path.of("./", args), new JavaFileObjectTest()); <----
>>>>> ERROR
>>>>
>>>> Do you have a module info?
>>>
>>>
>>> Yep:
>>>
>>>
>>> module PanamaMemTest
>>> {
>>> requires java.compiler;
>>> requires jdk.incubator.foreign;
>>> requires jdk.incubator.jextract;
>>>
>>> exports org.goliath.panamamemtest;
>>> }
>>
>> Ok - if you use a module info you have to say which modules you want
>> - and so you do need a requires java.compiler.
>>
>> So, your module info seems correct. Actually, I believe you only need
>> 'requires jdk.incubator.jextract' and that will also give you the
>> memory access API (jextract "transitively" requires it).
>>
>> Since everything seems almost correct here- how is the application
>> ran (by Netbeans) ? Is there any command line anywhere which gives
>> some hints as to whether netbeans is using classpath or modulepath
>> when running the Main class?
>
>
> Going by:
>
>
> <exec.args>-agentlib:jdwp=transport=dt_socket,server=n,address=${jpda.address}
> --add-modules
> jdk.incubator.foreign,jdk.incubator.jextract,java.compiler -classpath
> %classpath org.goliath.panamamemtest.PanamaMemTest</exec.args>
> <exec.executable>java</exec.executable>
>
So - it seems like the project is in a weird state. You have a module -
but the program is being executed using -classpath which I think means
your module-info is ignored.
In principle, if you have a module-info, and you use a module path, you
should not require any --add-modules. I suggest you try to compile from
the command line, and then execute also from command line, to rule out
Netbeans issues with module system.
Your java invocation should have the -p (or --module-path) option,
pointing to where your module is defined. And then the --module
<module>/<mainclass> to say what you actually want to execute. That
should load modules the right way, and pull in all the right dependencies.
Alternatively, if you just want to use classpath, drop the module-info
file - then remember to --add-modules jdk.incubator.jextract both when
compiling and executing.
Maurizio
>
> from nbactions.xml at the root of the project, classpath.
>
>
>>
>>>
>>>
>>> I'm using Netbeans 11.2, if that matters.
>>>
>>>
>>>> Or are you just running off the classpath?
>>>>
>>>> (btw, for now the jextract API doesn't really generate any bindings
>>>> - but it can be used to 'parse' an header and inspect the structure
>>>> of the declarations in it).
>>>
>>>
>>> I'm a bit confused here, your clang code that you linked is
>>> commented saying that it was generated by jextract. Is it internal
>>> still then?
>>
>> Yes, that jextract is still internal - we will open it up in the next
>> few weeks (shouldn't take too long).
>>
>> Maurizio
>>
>>>
>>>
>>>>
>>>> Maurizio
>>>>
>>>>>
>>>>>
>>>>> Exception:
>>>>>
>>>>>
>>>>> Exception in thread "main" java.lang.NoClassDefFoundError:
>>>>> javax/tools/JavaFileObject
>>>>> at
>>>>> jdk.incubator.jextract/jdk.internal.jextract.impl.Writer.resources(Writer.java:108)
>>>>> at
>>>>> jdk.incubator.jextract/jdk.internal.jextract.impl.Writer.writeAll(Writer.java:57)
>>>>> at
>>>>> jdk.incubator.jextract/jdk.internal.jextract.impl.JextractTaskImpl.write(JextractTaskImpl.java:65)
>>>>> at
>>>>> org.goliath.panamamemtest.PanamaMemTest.main(PanamaMemTest.java:37)
>>>>>
>>>>>
>>>>>>
>>>>>> Maurizio
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> -Sundar
>>>>>>>>
More information about the panama-dev
mailing list