Bob,
I think we are creating a property mess and still doesn't not cover all
cases.
So IMHO, it's better to create something like
os.arch.platform_string
and put there a string like
x86_64-pc-linux-gnu or armv7-linux-gnueabi-vfp
to solve immediate needs, then think about
good API to query capabilities for JDK9
-Dmitry
On 2013-01-09 00:29, Bob Vandette wrote:
> My team is in the process of proposing and implementing some System property
> changes for JDK8 to help
> identify specific processor characteristics and operating system platforms
> that might be needed in the future.
> The immediate need is for the detection of arm hard-float ABI but the other
> properties are being added in
> case we need them while the window is open.
>
>
> OS.ARCH ADDITIONS
> -----------------------------
>
> Embedded processors support a variety of CPU configurations that are not all
> binary compatible. If a developer needs to provide native binaries for one
> or more of these configurations, they need a way of querying the platform
> constraints in order to load the appropriate JNI shared library.
>
> Here's a specific example of this issue:
>
> There are three predominate binaries that we support Java for Linux ARM
> platforms on.
>
> 1. Full soft-floatABI (No floating point instructions)
>
> 2. VFP with softfp ABI (floating arguments are not passed in floating point
> registers)
>
> 3. VFP with hard float ABI (floating pointer arguments passes in registers)
>
> The first two (1,2) options are binary compatible at the ABI level. The only
> difference is the use of VFP instructions and if you are running on a
> processor that can execute them.
>
> The third option is a new ABI and is incompatible with the older ABIs unless
> you are running on a system that supports multi-arch.
>
> Developers are requesting a way to identify which ABI Java is currently using
> in order to select a compatible native library when using JNI.
>
>
>
> Solution
> I propose adding a few new System properties that can be used to provide
> additional
> information beyond the basic os.arch values for ARM as well as other processor
> architectures. These properties will all be optional. Although these
> properties are
> under the os name space, this was done to be consistent with the os.arch and
> other
> pre-existing properties. The new properties being define here define the mode
> in which the processor is being used by the running Java process rather than
> defining the capabilities of the OS. These are obviously related but the OS
> for example might be capable of running both 32 and 64 bit programs but the
> value returned for os.arch.datamodel will return 32 if the running process is
> a 32 bit Java process.
>
> os.arch.endian
> ---------------------
>
> This property if available will return either "big" or "little" depending on
> which endian mode the processor is executing in.
>
> os.arch.variant
> ---------------------
>
> This property, if available, is a free form description of the specific
> processor architecture. See examples below.
>
> os.arch.fpu
> ----------------
>
> This property, if available, describes the specific floating point execution
> unit that is being used by the Java process. If floating point instructions
> are emulated, this property will return "none".
>
> os.arch.abi
> ----------------
>
> This property, if available, describes if the floating point calling
> convention is hardfloat or softfloat.
>
> os.arch.datamodel
> ---------------------------
>
> This property, if available, reports that the running process is executing in
> either 32 bit or 64 bit mode.
>
> The "release" file located in the top level JRE directory should also be
> enhanced to include these new properties as OS_ARCH_ENDIAN, OS_ARCH_VARIANT,
> OS_ARCH_FPU, OS_ARCH_ABI and OS_ARCH_DATAMODEL.
>
> EXAMPLES
> ------------------
>
> Here are some options for ARM processors (os.arch == arm)
>
> os.arch.endian { big, little}
> os.arch.variant {cortex-a8, cortex-a9, armv5, armv6, armv7}
> os.arch.fpu {vfp, neon, none}
> os.arch.abi {softfloat, hardfloat}
> os.arch.datamodel {32, 64}
>
> Here are some options for PowerPC (os.arch == ppc)
>
> os.arch.endian { big, little}
> os.arch.variant {e500v2, e500mc, e600}
> os.arch.fpu {booke, altivec, spe, none }
> os.arch.abi {softfloat, hardfloat}
> os.arch.datamodel {32, 64}
>
> * although existing properties exist for datamodel and endian in the sun.*
> namespace, they are duplicated here
> for consistency and to make it easier for developers to find.
>
>
> OS.VARIANT ADDITIONS
> ------------------------------
>
> The current os.name System property does not provide sufficient information
> for identifying the specific platform that the Java runtime is running on.
> New platforms that are derived from existing platforms but have unique
> requirements may require special support. If someone were to port JDK8 to
> the Apple iOS platform, they could use much of the Mac OS X implemenation.
> This platform shares most of the same underlying operating system interfaces
> based on Darwin but some of the APIs are subsetted. A similar issue would
> arise in an attempt to support Java applications on Android operating systems
> which is a unique implementation of Linux.
>
>
> Interface summary
> exported external property os.variant, os.variant.version
>
> Solution
> I propose we add a new System property (os.variant) that will provide the
> specific OS implementation.
>
> Since Android is really a specific variant of Linux, os.name will report
> Linux while os.variant will report Android.
>
> In addition, we will add an os.variant.version that will report the specific
> version. In the Android example, os.version will report the underlying Linux
> version, but os.variant.version will report the Android specific version
> (2.6, 4.1 for example).
>
> For Apple, I propose to maintain the current Mac OS X value for os.name but
> use iPhone OS for the os.variant and the specific iPhone OS version for
> os.variant.version.
>
> These os.variant property will also be added to the "release" file located in
> the top level JRE directory as OS_VARIANT.
>
> Specification
> A new os.variant String property will be optionally available in a running
> Java process to identify which Operating System Platform the Java process is
> running on.
>
> A new os.variant.version String property will be available in a running Java
> process to identify the specific version of the Operating System Platform
> that the Java processes is currently executing on. This property is also
> optional.
>
> Examples of Operating System Platforms would be:
>
> Android
> iPhone OS
> Ubuntu
> Debian
> Raspbian
>
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
