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

[Samuel Audet]

About creating a "universal JAR", that will eventually get hard to 
provide at the level of jextract, because there are cases (C++...) when 
we will need to get information from native compilers that can only be 
executed under the actual native platforms (MSVC, Xcode, etc). What will 
happen in these cases is that the developer will obtain different JAR 
files from different platforms, and those can then be combined at a 
later stage, with a tool like the Maven Shade Plugin to create what is 
called "uber JAR" in its terminology. What is important at this stage is 
to make sure that it is possible to create those fat JARs easily from 
multiple JAR files created on different platforms--without conflicting 
resource names.

Samuel

On 03/08/2018 03:33 AM, Henry Jen wrote:
> On Mar 7, 2018, at 3:09 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> 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?
>>
> 
> Just to clarify that current descriptor implementation allows you to be specific.
> 
> There are descriptor with same C type meaning so that the generated jar can be as portable as C library is, and jextract is currently preserving C type as much as possible, which will be resolved at runtime.
> 
> I don’t think there is significant difference here, and I still like the convenience to have a portable jar if the native library is, although we knew it’s not always possible.
> 
>> 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.
>>
> 
> Agree, and if we ever want to support universal jar, this is a must have. But do we really need universal jar or a jar for each platform(as native bits has a target platform) is good enough?
> 
> Cheers,
> Henry
> 
>> 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.
>>>
>>>
>>
>