jextract to write classifies if a directory is specified with -o

[panama]

Llvm intermediate representation?

Just a thought.

Cheers,

Peter.

Sent from my Samsung device.
 
  Include original message
---- Original message ----
From: Samuel Audet <samuel.audet at gmail.com>
Sent: 08/03/2018 12:57:13 pm
To: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
Cc: panama-dev at openjdk.java.net
Subject: Re: jextract to write classifies if a directory is specified with -o

The way I see it is that we'll end up with bytecode that depends on both  
the native platform (Linux, Windows) and the native compiler we're  
targeting (GCC, MSVC, etc) 

The 2 most popular ways of dealing with this are: 
1. Place these "binaries" in special subdirectories/packages like on  
Android (/lib/armeabi, /lib/x86, etc in the APK), JNA, JNR, JavaCPP, etc 
2. Come up with "universal binaries" a la Mac, but in my opinion those  
are just JAR files done wrong, plus "universal bytecode" sounds  
strange... Maybe "fat bytecode"? :) 

So, unless there is another option available, the tooling should make it  
easy to do #1, which is basically what multi-release JAR files do, indeed! 

Samuel 

On 03/07/2018 08:09 PM, Maurizio Cimadamore wrote: 
> 
> On 07/03/18 10:12, Samuel Audet wrote: 
>> Hi, 
>> 
>> I would have a few questions before we can answer that I believe.  
>> Does the same JAR work for all platforms? Or does it generate, say,  
>> layouts which might differ between platforms? If so, how are these  
>> differences resolved at runtime? Does the user have to choose  
>> manually between different JAR files? 
> This is a very good question. I think right now, the metadata  
> generated by jextract is relatively platform independent - e.g. types  
> such as 'int' will turn into metadata such as 'i' - and then the  
> runtime can reason about it, compute alignment, sizes, etc. 
> 
> But this is not where we want to go longer term - as per my emails on  
> layout description, since we want such descriptions to cover both  
> C-like structs but also other kind of things (e.g. message protocols),  
> it is more important to have a 'precise' description, down to the bit  
> (well, maybe the byte). But this opens up the very question you raise  
> - if we go down that path, that means we get different artifacts from  
> jextract depending on the platform we're on. How do we make sure that,  
> at runtime, we get the right set of artifacts? 
> 
> I believe this problem is similar to multi release Jars - e.g. I have  
> a jar file that has some classes for JDK 7, some other classes for 8  
> and some other deltas for 9 - how does the runtime resolve it to point  
> at the right set of classes? I hope we can 'steal' something from that  
> logic in order to give our jars a little bit more structure, and then  
> have the right thing/selection happen at runtime. 
> 
> Maurizio 
>> 
>> Samuel 
>> 
>> 2018/03/07 18:32 "Maurizio Cimadamore"  
>> <maurizio.cimadamore at oracle.com  
>> <mailto:maurizio.cimadamore at oracle.com>>: 
>> 
>>     Javac does not support this feature. And, I think if it did, it 
>>     would safe to assume that it would use a different option than -d, 
>>     which comes with a significant JavaFileManager baggage. I'd 
>>     probably see it more as a post-processing step which, after 
>>     placing your classfiles in the -d folder, it would also generate a 
>>     jarfile where you want it to be (to mimic how users typically do 
>>     it by piping multiple shell commands). 
>> 
>>     On a related point, while javac doesn't have a 'jar' mode, the VM 
>>     launcher does - and that option is called '-jar'. Any reason as 
>>     why we can't reuse that name here? 
>> 
>>     Maurizio 
>> 
>> 
>>     On 07/03/18 03:42, John Rose wrote: 
>> 
>>         +1  BTW, can javac emit its results directly to a jar? If it  
>> did, 
>>         what would that look like? 
>> 
>>         On Mar 6, 2018, at 8:36 AM, Sundararajan Athijegannathan 
>>         <sundararajan.athijegannathan at oracle.com 
>> <mailto:sundararajan.athijegannathan at oracle.com>> wrote: 
>> 
>>             I wonder if we should have -d (for directory) option for 
>>             directory for output. That would make it consistent with 
>>             other tools like javac. With -d, we can create directory 
>>             if it does not exist. 
>> 
>> 
> 
>