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
