<?xml version="1.0" encoding="UTF-8"?>
<!--

    Licensed to the Apache Software Foundation (ASF) under one
    or more contributor license agreements.  See the NOTICE file
    distributed with this work for additional information
    regarding copyright ownership.  The ASF licenses this file
    to you under the Apache License, Version 2.0 (the
    "License"); you may not use this file except in compliance
    with the License.  You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing,
    software distributed under the License is distributed on an
    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
    KIND, either express or implied.  See the License for the
    specific language governing permissions and limitations
    under the License.

-->
<?xml-stylesheet type="text/xml" href="../../nbbuild/javadoctools/apichanges.xsl"?>
<!DOCTYPE apichanges PUBLIC "-//NetBeans//DTD API changes list 1.0//EN" "../../nbbuild/javadoctools/apichanges.dtd">
<apichanges>
    <apidefs>
        <apidef name="keyring">Keyring API</apidef>
    </apidefs>
    <changes>
        <change id="edt">
            <api name="keyring"/>
            <summary>Keyring API usable from any thread</summary>
            <version major="1" minor="10"/>
            <date day="6" month="1" year="2012"/>
            <author login="phejl"/>
            <compatibility>
                <p>
                    Existing callers should use the Keyring directly from
                    any thread and should not try to avoid EDT anymore.
                </p>
                <p>
                    SPI implementors should not be changed and they may
                    continue to assume that they will not be called directly
                    from EDT.
                </p>
            </compatibility>
            <description>
                <p>
                    It hasn't been allowed to call the Keyring from EDT.
                    This change removes the limitation as the need to read
                    password from the UI is not so rare. To resolve this people
                    had to code custom threading solution to prevent possible
                    deadlock on fallback implementation of the keyring API.
                </p>
            </description>
            <class package="org.netbeans.api.keyring" name="Keyring"/>
            <issue number="206475"/>
        </change>
        <change id="initial">
            <api name="keyring"/>
            <summary>Keyring API created</summary>
            <version major="1" minor="0"/>
            <date day="11" month="12" year="2009"/>
            <author login="jglick"/>
            <compatibility>
                <p>
                    Modules formerly storing passwords in some other way should
                    not only begin using <code>Keyring</code>, but also delete any
                    passwords from the old storage as they are transferred.
                </p>
            </compatibility>
            <description>
                <p>
                    A new API was created for securely storing user passwords.
                    Where possible it uses a native keyring.
                </p>
            </description>
            <issue number="173413"/>
        </change>
    </changes>
    <htmlcontents>
<!-- Generated from apichanges.xml -->
    <head>
      <title>Change History for the Keyring API</title>
      <link rel="stylesheet" href="prose.css" type="text/css"/>
    </head>
    <body>
<p class="overviewlink"><a href="@TOP@/overview-summary.html">Overview</a></p>
<h1>Introduction</h1>
<p>This document lists changes made to the <a href="@TOP@/overview-summary.html">CHANGEME API</a>.</p>
      <hr/>
      <standard-changelists module-code-name="org.netbeans.modules.keyring"/>
      <hr/><p>@FOOTER@</p>
    </body>
  </htmlcontents>
</apichanges>