I agree but I am not sure any member has enough interest to drive that through
a spec. It would still require the VMs to report it properly.
Kind regards,
Peter Kriens
> On 13 Apr 2020, at 19:57, chris.g...@kiffer.be wrote:
>
> Hi Peter,
>
> I would argue that it is "os.arch" which is a bit of a mess, because it
> attempts to represent too much in a single name. Compare this with the set
> of "triples" here :
> http://llvm.org/doxygen/classllvm_1_1Triple.html
>
> I would argue that these definitions would be a more useful way to specify
> the target for native code, as they correspond to the way that code is
> compiled for the various targets.
>
> Kind Regards
>
> Chris
>
>
>> That is my experience on the ARM processor, there are so many variations,
>> 32/64, le/be, floating point/no floating point, etc. that it is a bit of a
>> mess.
>>
>> In general, on ARM I see people define the properties themselves to
>> whatever the VM they use reports.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>>> On 13 Apr 2020, at 18:22, Markus Rathgeb via osgi-dev
>>> <osgi-dev@mail.osgi.org> wrote:
>>>
>>> This has been already done by someone here:
>>> https://stackoverflow.com/a/57893125
>>> It seems os.arch is not really "stable" at all:
>>> https://bugs.openjdk.java.net/browse/JDK-8167584
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>
>
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
