New CPU & OS Platform System Properties

[John Coomes]

Bob Vandette (bob.vandette at oracle.com) 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
> -----------------------------
> ...
> 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.

The property name os.arch.abi is too generic to be used only for
floating point info; os.arch.abi.float (or similar) would be better.
Unless you expect this property to contain a list of values describing
various abi properties in the future.

> os.arch.datamodel
> ---------------------------
>  
> This property, if available, reports that the running process is executing in either 32 bit or 64 bit mode.

os.arch.datamodel should be os.arch.data.model (similar to
sun.arch.data.model), since it's both familiar and easier to read.

The endian property also relates to the data format of the
architecture; it could be renamed os.arch.data.endian.

-John

> 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
> 
>