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