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

[Maurizio Cimadamore]

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