8214568: Use {@systemProperty} for definitions of system properties
authorweijun
Thu, 13 Dec 2018 12:03:03 +0800
changeset 52997 85ade44f351a
parent 52996 2457d862a646
child 52998 77f31b03cc0e
8214568: Use {@systemProperty} for definitions of system properties Reviewed-by: xuelei
src/java.security.jgss/share/classes/javax/security/auth/kerberos/package-info.java
src/java.security.jgss/share/classes/org/ietf/jgss/package-info.java
src/java.security.jgss/share/classes/org/ietf/jgss/package.html
src/jdk.security.auth/share/classes/com/sun/security/auth/login/ConfigFile.java
src/jdk.security.auth/share/classes/com/sun/security/auth/module/Krb5LoginModule.java
--- a/src/java.security.jgss/share/classes/javax/security/auth/kerberos/package-info.java	Thu Dec 13 11:16:33 2018 +0800
+++ b/src/java.security.jgss/share/classes/javax/security/auth/kerberos/package-info.java	Thu Dec 13 12:03:03 2018 +0800
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -38,10 +38,10 @@
  *
  * You can provide the name of your default realm and Key Distribution
  * Center (KDC) host for that realm using the system properties
- * {@code java.security.krb5.realm} and {@code java.security.krb5.kdc}.
- * Both properties must be set.
- * Alternatively, the {@code java.security.krb5.conf} system property can
- * be set to the location of an MIT style {@code krb5.conf} configuration
+ * {@systemProperty java.security.krb5.realm} and
+ * {@systemProperty java.security.krb5.kdc}. Both properties must be set.
+ * Alternatively, the {@systemProperty java.security.krb5.conf} system property
+ * can be set to the location of an MIT style {@code krb5.conf} configuration
  * file. If none of these system properties are set, the {@code krb5.conf}
  * file is searched for in an implementation-specific manner. Typically,
  * an implementation will first look for a {@code krb5.conf} file in
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/src/java.security.jgss/share/classes/org/ietf/jgss/package-info.java	Thu Dec 13 12:03:03 2018 +0800
@@ -0,0 +1,121 @@
+/*
+ * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.  Oracle designates this
+ * particular file as subject to the "Classpath" exception as provided
+ * by Oracle in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
+ * or visit www.oracle.com if you need additional information or have any
+ * questions.
+ */
+
+/**
+ * This package presents a framework that allows application developers to
+ * make use of security services like authentication, data integrity and
+ * data confidentiality from a variety of underlying security mechanisms
+ * like Kerberos, using a unified API. The security mechanisms that an
+ * application can
+ * chose to use are identified with unique object identifiers. One example
+ * of such a mechanism is the Kerberos v5 GSS-API mechanism (object
+ * identifier 1.2.840.113554.1.2.2). This mechanism is available through
+ * the default instance of the GSSManager class.<p>
+ *
+ * The GSS-API is defined in a language independent way in
+ * <a href=http://www.ietf.org/rfc/rfc2743.txt>RFC 2743</a>. The Java
+ * language bindings are defined in
+ * <a href=http://www.ietf.org/rfc/rfc2853.txt>RFC 2853</a><p>
+ *
+ * An application starts out by instantiating a {@code GSSManager}
+ * which then serves as a factory for a security context. An application
+ * can use specific principal names and credentials that are also created
+ * using the GSSManager; or it can instantiate a
+ * context with system defaults. It then goes through a context
+ * establishment loop. Once a context is established with the
+ * peer, authentication is complete. Data protection such as integrity
+ * and confidentiality can then be obtained from this context.<p>
+ *
+ * The GSS-API does not perform any communication with the peer. It merely
+ * produces tokens that the application must somehow transport to the
+ * other end.
+ *
+ * <h3 id="useSubjectCredsOnly">Credential Acquisition</h3>
+ * The GSS-API itself does not dictate how an underlying mechanism
+ * obtains the credentials that are needed for authentication. It is
+ * assumed that prior to calling the GSS-API, these credentials are
+ * obtained and stored in a location that the mechanism provider is
+ * aware of. However, the default model in the Java platform will be
+ * that mechanism providers must obtain credentials only from the private
+ * or public credential sets associated with the
+ * {@link javax.security.auth.Subject Subject} in the
+ * current access control context.  The Kerberos v5
+ * mechanism will search for the required INITIATE and ACCEPT credentials
+ * ({@link javax.security.auth.kerberos.KerberosTicket KerberosTicket} and
+ * {@link javax.security.auth.kerberos.KerberosKey KerberosKey}) in
+ * the private credential set where as some other mechanism might look
+ * in the public set or in both.  If the desired credential is not
+ * present in the appropriate sets of the current Subject, the GSS-API
+ * call must fail.<p>
+ *
+ * This model has the advantage that credential management
+ * is simple and predictable from the applications point of view.  An
+ * application, given the right permissions, can purge the credentials in
+ * the Subject or renew them using standard Java API's.  If it purged
+ * the credentials, it would be sure that the JGSS mechanism would fail,
+ * or if it renewed a time based credential it would be sure that a JGSS
+ * mechanism would succeed.<p>
+ *
+ * This model does require that a {@link
+ * javax.security.auth.login JAAS login} be performed in order to
+ * authenticate and populate a Subject that the JGSS mechanism can later
+ * utilize. However, applications have the ability to relax this
+ * restriction by means of a system property:
+ * {@systemProperty javax.security.auth.useSubjectCredsOnly}. By default
+ * this system property will be assumed to be {@code true} (even when
+ * it is unset) indicating that providers must only use the credentials
+ * that are present in the current Subject. However, if this property is
+ * explicitly set to false by the application, then it indicates that
+ * the provider is free to use any credentials cache of its choice. Such
+ * a credential cache might be a disk cache, an in-memory cache, or even
+ * just the current Subject itself.
+ *
+ * <h2>Related Documentation</h2>
+ * <p>
+ * For an online tutorial on using Java GSS-API, please see
+ * {@extLink security_guide_jgss_tutorial
+ * Introduction to JAAS and Java GSS-API}.
+ * </p>
+ *
+ * <!--
+ * <h2>Package Specification</h2>
+ *
+ * ##### FILL IN ANY SPECS NEEDED BY JAVA COMPATIBILITY KIT #####
+ * <ul>
+ * <li><a href="">##### REFER TO ANY FRAMEMAKER SPECIFICATION HERE #####</a>
+ * </ul>
+ *
+ * <h2>Related Documentation</h2>
+ *
+ * For overviews, tutorials, examples, guides, and tool documentation, please see:
+ * <ul>
+ * <li><a href="">##### REFER TO NON-SPEC DOCUMENTATION HERE #####</a>
+ * </ul>
+ *
+ * -->
+ *
+ * @since 1.4
+ * */
+package org.ietf.jgss;
--- a/src/java.security.jgss/share/classes/org/ietf/jgss/package.html	Thu Dec 13 11:16:33 2018 +0800
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,126 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<html>
-<head>
-<!--
-Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved.
-DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
-
-This code is free software; you can redistribute it and/or modify it
-under the terms of the GNU General Public License version 2 only, as
-published by the Free Software Foundation.  Oracle designates this
-particular file as subject to the "Classpath" exception as provided
-by Oracle in the LICENSE file that accompanied this code.
-
-This code is distributed in the hope that it will be useful, but WITHOUT
-ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
-FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
-version 2 for more details (a copy is included in the LICENSE file that
-accompanied this code).
-
-You should have received a copy of the GNU General Public License version
-2 along with this work; if not, write to the Free Software Foundation,
-Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
-
-Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
-or visit www.oracle.com if you need additional information or have any
-questions.
--->
-
-</head>
-<body bgcolor="white">
-
-    This package presents a framework that allows application developers to
-    make use of security services like authentication, data integrity and
-    data confidentiality from a variety of underlying security mechanisms
-    like Kerberos, using a unified API. The security mechanisms that an
-    application can
-    chose to use are identified with unique object identifiers. One example 
-    of such a mechanism is the Kerberos v5 GSS-API mechanism (object
-    identifier 1.2.840.113554.1.2.2). This mechanism is available through
-    the default instance of the GSSManager class.<p>
-
-    The GSS-API is defined in a language independent way in 
-    <a href=http://www.ietf.org/rfc/rfc2743.txt>RFC 2743</a>. The Java
-    language bindings are defined in 
-    <a href=http://www.ietf.org/rfc/rfc2853.txt>RFC 2853</a><p>
-
-    An application starts out by instantiating a <code>GSSManager</code>
-    which then serves as a factory for a security context. An application
-    can use specific principal names and credentials that are also created
-    using the GSSManager; or it can instantiate a
-    context with system defaults. It then goes through a context
-    establishment loop. Once a context is established with the
-    peer, authentication is complete. Data protection such as integrity
-    and confidentiality can then be obtained from this context.<p>
-
-    The GSS-API does not perform any communication with the peer. It merely 
-    produces tokens that the application must somehow transport to the
-    other end.
-
-<h3 id="useSubjectCredsOnly">Credential Acquisition</h3>
-    The GSS-API itself does not dictate how an underlying mechanism
-    obtains the credentials that are needed for authentication. It is
-    assumed that prior to calling the GSS-API, these credentials are
-    obtained and stored in a location that the mechanism provider is
-    aware of. However, the default model in the Java platform will be
-    that mechanism providers must obtain credentials only from the private
-    or public credential sets associated with the
-    {@link javax.security.auth.Subject Subject} in the
-    current access control context.  The Kerberos v5  
-    mechanism will search for the required INITIATE and ACCEPT credentials 
-    ({@link javax.security.auth.kerberos.KerberosTicket KerberosTicket} and
-     {@link javax.security.auth.kerberos.KerberosKey KerberosKey}) in
-    the private credential set where as some other mechanism might look
-    in the public set or in both.  If the desired credential is not
-    present in the appropriate sets of the current Subject, the GSS-API
-    call must fail.<p>
-
-    This model has the advantage that credential management
-    is simple and predictable from the applications point of view.  An
-    application, given the right permissions, can purge the credentials in
-    the Subject or renew them using standard Java API's.  If it purged
-    the credentials, it would be sure that the JGSS mechanism would fail,
-    or if it renewed a time based credential it would be sure that a JGSS
-    mechanism would succeed.<p>
-
-    This model does require that a {@link
-    javax.security.auth.login JAAS login} be performed in order to
-    authenticate and populate a Subject that the JGSS mechanism can later 
-    utilize. However, applications have the ability to relax this
-    restriction by means of a system property:
-    <code>javax.security.auth.useSubjectCredsOnly</code>. By default
-    this system property will be assumed to be <code>true</code> (even when
-    it is unset) indicating that providers must only use the credentials
-    that are present in the current Subject. However, if this property is
-    explicitly set to false by the application, then it indicates that
-    the provider is free to use any credentials cache of its choice. Such
-    a credential cache might be a disk cache, an in-memory cache, or even
-    just the current Subject itself.
-
-<h2>Related Documentation</h2>
-<p>
-For an online tutorial on using Java GSS-API, please see
-{@extLink security_guide_jgss_tutorial
-Introduction to JAAS and Java GSS-API}.
-</p>
-
-<!--
-<h2>Package Specification</h2>
-
-##### FILL IN ANY SPECS NEEDED BY JAVA COMPATIBILITY KIT #####
-<ul>
-  <li><a href="">##### REFER TO ANY FRAMEMAKER SPECIFICATION HERE #####</a>
-</ul>
-
-<h2>Related Documentation</h2>
-
-For overviews, tutorials, examples, guides, and tool documentation, please see:
-<ul>
-  <li><a href="">##### REFER TO NON-SPEC DOCUMENTATION HERE #####</a>
-</ul>
-
--->
-
-@since 1.4
-</body>
-</html>
--- a/src/jdk.security.auth/share/classes/com/sun/security/auth/login/ConfigFile.java	Thu Dec 13 11:16:33 2018 +0800
+++ b/src/jdk.security.auth/share/classes/com/sun/security/auth/login/ConfigFile.java	Thu Dec 13 12:03:03 2018 +0800
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -55,8 +55,8 @@
  *   each configuration.
  *
  * <li>
- *   The {@code java.lang.System} property
- *   <i>java.security.auth.login.config</i>
+ *   The system property
+ *   {@systemProperty java.security.auth.login.config}
  *   may also be set to a {@code URL} pointing to another
  *   login configuration file
  *   (which is the case when a user uses the -D switch at runtime).
--- a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/Krb5LoginModule.java	Thu Dec 13 11:16:33 2018 +0800
+++ b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/Krb5LoginModule.java	Thu Dec 13 12:03:03 2018 +0800
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -84,7 +84,7 @@
  * by using the option {@code principal}. The principal name
  * can either be a simple user name, a service name such as
  * {@code host/mission.eng.sun.com}, or "*". The principal can also
- * be set using the system property {@code sun.security.krb5.principal}.
+ * be set using the system property {@systemProperty sun.security.krb5.principal}.
  * This property is checked during login. If this property is not set, then
  * the principal name from the configuration is used. In the
  * case where the principal property is not set and the principal