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

[Samuel Audet]

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.
>>
>>
>
>