JDK-6547117 : System.getProperty is the only way to get some info, but it may throw exception
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 6
  • Priority: P5
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-04-17
  • Updated: 2017-05-04
  • Resolved: 2017-05-04
Related Reports
Relates :  
JDK-6370159 - (enum) Create an enum for standard System property keys.
Description
FULL PRODUCT VERSION :
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b11)
Java HotSpot(TM) Client VM (build 1.7.0-ea-b11, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
JavaDoc comment for System.getProperty method contains the following: "...if there is a security manager, its <code>checkPropertyAccess</code> method is called with the key as its argument. This may result in a SecurityException."

But there are several keys that provides an important information, that can be needful in any type of software (including Java applets) and cannot be got by any other ways. Today it is version information: "java.version", "java.vm.specification.version", "os.arch", "os.name", etc. (Before Java 1.5, there was another important property "line.separator", but now it can be retreived by String.format("%n").)

So, the current situation is strange enough. In fact, we may and should use System.getProperty("java.version") for getting Java version: there are no popular security managers that will decline this request. But according API specification we MUST NOT do this. Moreover, some user's custom security manager really may decline such property request; it, for example, may lead to unexpected failure in a Java library that calls System.getProperty("java.version") while initialization of some class. As a result, the authors of common libraries (as me) are enforced to use some unbeautiful tricks as Class.forName("SomeClassThatWasAddedInJava5") with catching exceptions to detect the current Java version.

I think it's necessary either to correct System.getProperty so that it will not call SecurityManager for some little set of standard keys, as "java.version", and document this behavior, or (I think better) to provide alternate way to get the corresponding information. For example, all version information could be incapsulated in a special "Version" class with static generation methods as "Version getJavaVersion()", "Version getVMSpecificationVersion()", "Version getPackageVersion(Package p)", etc. and access methods as "int getMajorVersion()", "int getUpdateNumber()", etc.
Comments
Java 9 introduces java.lang.Runtime.Version, which is an API for dealing with version information. The current version is returned by calling Runtime.version(). Other important system properties are also covered by APIs: line.separator => java.lang.System.lineSeparator() file.separator => java.io.File.separator path.separator => java.io.File.pathSeparator Most non-sensitive system property information is now covered by other APIs. Other information (user home directory, OS version, etc.) potentially leaks valuable information to attackers, so it should be protected by the SecurityManager. Closing this issue as Not an Issue.
04-05-2017
EVALUATION It seems unlikely that an alternative mechanism is justified here. The defect reports that are not ever received, as far as I know, are ones complaining that System.getProperty *did* fail because a security policy was defined that *was* so strict it cut off access to this information. The submitter is asking for tools to program around a site-administrative problem that could be relevent to any property, not just the submitter's set that are implicitly designated "essential." So, if there was a judgement that property access should be given selective immunity from security policies it would likely become a slippery slope, resulting in a larger collection than the few methods requested here. Finally, there are backward compatibility issues involved, although existing dependence on security policies cutting off access to the key values mentioned seems unlikely. If, however, there is concensus agreement for "categories" of properties for which security controls are inappropriate, there seems to be a better alternative to individual accessor methods in the form of enhancement change request 6370159, which calls for a mapping of property keys to an enum.
23-04-2007