home *** CD-ROM | disk | FTP | other *** search
/ BUG 15 / BUGCD1998_06.ISO / aplic / jbuilder / jruntime.z / CHANGES < prev    next >
Text File  |  1997-08-25  |  81KB  |  2,017 lines
  1.                          
  2.                             CHANGES
  3.  
  4.                     Java(tm) Development Kit
  5.                          JDK(tm) 1.1.2
  6.  
  7. -----------------------------------------------------------------------
  8. CONTENTS
  9. -----------------------------------------------------------------------
  10. This document describes the changes between the various JDK 
  11. releases of the Java Platform 1.1.  It is divided into several 
  12. sections:
  13.  
  14.     - Changes from JDK 1.1.1 to JDK 1.1.2
  15.     - Changes from JDK 1.1_Final to JDK 1.1.1_Final
  16.     - Changes from JDK 1.1beta3  to JDK 1.1_Final
  17.     - Changes from JDK 1.1beta2  to JDK 1.1beta3
  18.     - Changes from the original JDK 1.1beta to JDK 1.1beta2
  19.  
  20. Changes within a section are in this order:
  21.     - VERSION NUMBER
  22.     - BUG FIXES
  23.     - TEXT CHANGES
  24.     - AWT CHANGES
  25.     - BEANS CHANGES
  26.     - SECURITY CHANGES
  27.     - JAR CHANGES
  28.     - LANG CHANGES
  29.     - IO CHANGES
  30.     - JAVA NATIVE INTERFACE CHANGES
  31.     - TOOL CHANGES
  32.  
  33.     ---------------------------------------------------------
  34.     NOTE: To find the Java version number, execute:
  35.           java -version
  36.     ---------------------------------------------------------
  37.     NOTE: Another significant list of changes is our
  38.           important bug fixes, available from our JavaSoft 
  39.           website:
  40.           http://java.sun.com/products/jdk/1.1/fixedbugs/
  41.     ---------------------------------------------------------
  42.     NOTE: Known bugs are listed at:
  43.           http://java.sun.com/products/jdk/1.1/knownbugs/
  44.     ---------------------------------------------------------
  45.  
  46. =======================================================================
  47. Changes from JDK 1.1.1 to JDK 1.1.2
  48. -----------------------------------------------------------------------
  49.  
  50. JDK 1.1.2 is a bug-fix release. The following is a list of important 
  51. bug fixes and other changes in JDK 1.1.2.
  52. ______________
  53. VERSION NUMBER - The version number for this release is "JDK1.1.2".
  54.  
  55. ____________
  56. VERIFIER BUG - The JDK 1.1.1 bytecode verifier did not check to 
  57. determine whether the number of arguments passed into a method is less 
  58. than the amount of memory allocated to local variables for that 
  59. method. There was no known security attack based on this bug. This bug 
  60. has been corrected in JDK 1.1.2.
  61.  
  62. ___________
  63. SIGNING BUG - In JDK 1.1.1, digitally signed code could be 
  64. manipulated to impersonate another digital signature from the list of 
  65. signers that are recorded in the Java runtime. This bug has been 
  66. fixed in JDK 1.1.2. [Bug 4048143]
  67.  
  68. _______
  69. DSA BUG - In JDK 1.1.1, the same default seed was used for every 
  70. invocation of DSA. This bug has been fixed in JDK 1.1.2. 
  71. [Bug 4050406]
  72.  
  73. ________________
  74. AWT MENU BUG FIX - Trying to add a pull-right cascade menu to a 
  75. PopupMenu in JDK 1.1.1 led to an exception. This problem did not 
  76. exist in JDK 1.1. This bug has been corrected in JDK 1.1.2.
  77. [Bug 4039089]
  78.  
  79. _________________________________
  80. AWT LIGHTWEIGHT COMPONENT BUG FIX - Mouse tracking events for 
  81. lightweight components were not being delivered in some situations. 
  82. This bug has been fixed in JDK 1.1.2.  [Bug 4038897]
  83.  
  84. ___________________
  85. AWT REPAINT BUG FIX - Some components were not being repainted 
  86. properly in some situations in JDK 1.1.1. This problem did not 
  87. exist in JDK 1.1. This bug has been fixed in JDK 1.1.2.
  88. [Bug 4040638]
  89.  
  90. __________________
  91. AWT DIALOG BUG FIX - Closing nested modal dialogs out of order would 
  92. cause parent to remain disabled in some cases. This bug has been fixed 
  93. in JDK1.1.2.  [Bug 4045610]
  94.  
  95. _________________
  96. AWT FOCUS BUG FIX - Setting default focus caused applets to hang in 
  97. some situations. This problem did not exist in JDK 1.1. This bug 
  98. has been fixed in JDK 1.1.2.  [Bug 4038896]
  99.  
  100. ____________________
  101. APPLETVIEWER BUG FIX - Trying to save an applet from the Appletviewer 
  102. led to an exception. This bug has been fixed in JDK 1.1.2.
  103. [Bug 4036537]
  104.  
  105. ________________
  106. DEBUGGER BUG FIX - The debugger "dump" command converted double 
  107. values to float values before displaying them. This bug has been fixed 
  108. in JDK 1.1.2.  [Bug 4046775]
  109.  
  110. _______________
  111. JAVADOC BUG FIX - The javadoc html output for interfaces repeated 
  112. the word "interface" in the signature. This bug has been fixed in 
  113. JDK 1.1.2.  [Bug 4041579]
  114.  
  115. _________________________
  116. NEW jre COMMAND-LINE TOOL - The jre command-line tool is similar to 
  117. the java command-line tool, but is intended primarily for end users 
  118. who do not require the development-related options available with 
  119. the java tool. For more information on the jre tool, see 
  120. http://java.sun.com/products/jdk/1.1/docs/tooldocs/solaris/jre.html
  121. or http://java.sun.com/products/jdk/1.1/docs/tooldocs/win32/jre.html. 
  122. Source code for the jre tool can be found in the Windows JDK 1.1.2 
  123. directory tree in the jdk1.1.2\demo\jre\win32 folder. In the 
  124. Solaris JDK 1.1.2, jre source files can be found in the 
  125. jdk1.1.2/demo/jre/solaris directory.
  126.  
  127.  
  128. =======================================================================
  129. Changes from JDK 1.1_Final to JDK 1.1.1
  130. -----------------------------------------------------------------------
  131.  
  132. The following changes and bug fixes are in the JDK 1.1.1 final release.
  133. This is a bug fix release.
  134. ______________
  135. VERSION NUMBER - The version number for this release is "JDK1.1.1". 
  136.  
  137. _________
  138. BUG FIXES - This version contains the bug fixes listed at the 
  139.     web page mentioned above. 
  140.  
  141. ____________
  142. UTIL BUG FIX - Removed getMenu and getMenuBar methods from 
  143.     util.ResourceBundle class. [Bug 4036076]
  144.  
  145.     This bug fix is mentioned here because it fixes an API bug
  146.     in JDK 1.1.
  147.  
  148.     These two "convenience" methods were part of the beta release
  149.     and were mistakenly left in the final JDK 1.1 after we
  150.     discovered the design weakness they presented and decided to
  151.     remove them.  It is a bug that they were included in the 1.1
  152.     release, and you should not call these methods.   We have 
  153.     removed them in 1.1.1.  Being convenience methods, they are not 
  154.     essential, and alternate coding is simple.   
  155.  
  156.     To be more specific, the ResourceBundle class in JDK 1.1 
  157.     included the two methods:
  158.  
  159.     public final Menu getMenu(String key) 
  160.         throws MissingResourceException {
  161.              return (Menu) getObject(key);
  162.          }
  163.  
  164.      public final MenuBar getMenuBar(String key) 
  165.         throws MissingResourceException {
  166.              return (MenuBar) getObject(key);
  167.      }
  168.  
  169.     These "convenience" methods saved the user from having to
  170.     explicitly cast objects in a ResourceBundle that happened to 
  171.     be of type Menu or MenuBar, such as:
  172.     
  173.        (Menu)rb.getObject(key)
  174.     
  175.     The side effect was that by returning types Menu and MenuBar, this 
  176.     class referred to the awt package.  ResourceBundle is a relatively 
  177.     low level piece of the core however while AWT is a relatively high 
  178.     level piece. This dependency caused a number of problems.  Most 
  179.     notably it did not allow a Java runtime environment to be created 
  180.     that omitted the AWT package (such as in a server).
  181.     
  182.     Removing this dependency on AWT required removing these APIs 
  183.     completely from ResourceBundle.  This change, of course, breaks 
  184.     code that calls these methods.  The upside is that these two APIs 
  185.     were of very little marginal value.  They simply saved the user 
  186.     the effort of typing an explicit cast. Furthermore, since these
  187.     two methods were new at 1.1, they have not been available for
  188.     very long. 
  189.  
  190. _____________________
  191. AWT COMPONENT BUG FIX - Changed the field java.awt.Component.locale
  192.     from protected to private.  
  193.  
  194.     The locale field is accessible through getLocale() and 
  195.     setLocale() methods, and all code should be using those.  
  196.     This change is necessary to support future development of 
  197.     the lightweight framework.
  198.  
  199. ________________________
  200. AWT DATATRANSFER BUG FIX - Corrected the MIME type for DataFlavor.
  201.     [Bug 4037854]
  202.  
  203.     In JDK 1.1, java.awt.datatransfer.DataFlavor used the wrong MIME
  204.     type.  DataFlavor claimed that the MIME type for a java 
  205.     serialized object was: 
  206.  
  207.        application/x-javaserializedobject 
  208.  
  209.     This name is inconsistent with other existing names and common
  210.     conventions. The name has been corrected by adding hypens to it, 
  211.     as follows:
  212.  
  213.        application/x-java-serialized-object 
  214.  
  215.     This makes it consistent with: 
  216.  
  217.        application/java-vm 
  218.        application/x-java-vm 
  219.        application/x-java-archive 
  220.  
  221. ____________
  222. FONT CHANGES - Times, Helvetica, and Courier are now mapped to
  223.     Latin1 characters.
  224.  
  225.     Times, Helvetica, and Courier fonts are no longer mapped to 
  226.     non-Latin1 classes of fonts, such as Symbol or ZapfDingabats.
  227.     These three fonts are now mapped to Latin1 characters, just like
  228.     they were in version 1.0.
  229.  
  230.     If you want to have non-Latin1 characters, you must map fonts
  231.     such as Symbol and ZapfDingabats to the Java virtual fonts.  These
  232.     virtual font classes are Serif, Sans-serif, Monospaced, Dialog, 
  233.     and DialogInput.
  234.     
  235.  
  236. ===================================================================
  237. Changes from JDK 1.1beta3 to JDK 1.1_Final
  238. -------------------------------------------------------------------
  239.  
  240. The following changes and bug fixes are in the JDK 1.1 final release.
  241.  
  242. ______________
  243. VERSION NUMBER - The version number for this release is "JDK1.1_Final". 
  244.     Throughout the documentation we call it simply "JDK1.1"
  245.  
  246. ____________
  247. TEXT CHANGES - Extensive surface changes to Text package
  248.  
  249.     The following extensive changes in the Text package are the
  250.     result of a design review recently carried out to
  251.     simplify, rationalize and properly abstract the 
  252.     internationalization API.  We realized this would 
  253.     make a significant improvement in learning and using 
  254.     internationalization in Java.  
  255.  
  256.     The changes involve mostly surface changes, such as 
  257.     renaming and moving API, and changing the order of arguments,
  258.     to better conform with conventions established with the rest
  259.     of Java.
  260.  
  261. ____________
  262. TEXT CHANGES - CharacterIterator
  263.  
  264.     Removed getText method. CharacterIterators are intended to allow character
  265.     at a time access to text without exposing how the text is actually stored.
  266.     It is expected that some CharacterIterators will operate on text that can
  267.     not easily or efficiently be stored as a String. Accessing the text as a
  268.     whole should be the responsibility of the text object.
  269.  
  270.     Rename startIndex to getBeginIndex and rename endIndex to
  271.     getEndIndex. This is to follow established naming patterns for getters and
  272.     setters as well as java.lang.String's convention for identifying ranges in
  273.     text.
  274.  
  275. ____________
  276. TEXT CHANGES - ChoiceFormat
  277.  
  278.     Changed the constructor to take an array of Strings rather than an array
  279.     of Objects.  String were the only type that made sense in this context.
  280.  
  281.     Changed the setChoices method to take an array of Strings rather than an
  282.     array of Objects.  String were the only type that made sense in this
  283.     context.  
  284.  
  285.     Added applyPattern and toPattern methods similar to the methods on other 
  286.     Format classes.
  287.  
  288.     Changed the format methods to take a FieldPosition rather than a
  289.     FormatStatus argument. See the change description for FormatStatus.
  290.     
  291.     Changed the parse method to take a ParsePosition rather than a ParseStatus
  292.     argument. See the change description for ParseStatus.
  293.     
  294.     Added clone, hashCode and equals methods.  These are standard overrides
  295.     and do not change the semantics.
  296.  
  297. ____________
  298. TEXT CHANGES - Collation
  299.  
  300.     Renamed class "Collator".  It was not clear from the old name whether this
  301.     class actually did collation or simply represented a set of collation
  302.     rules.  The new name makes it clear that the class performs string
  303.     comparisons.
  304.     
  305.     Removed the constants LESS, EQUAL and GREATER. Changed the compare methods
  306.     to return the int value -1, 0 or 1 instead of LESS, EQUAL or GREATER. This
  307.     follows the pattern used by the java.lang.String.compareTo method.
  308.     
  309.     Removed the greater and greaterOrEqual methods.  The same information is
  310.     provided by the compare method.  Having only a compare and and equals 
  311.     method mimics the comparison API provided by java.lang.String.
  312.     
  313.     Removed the compare(String, int, int, String, int, int) version of the
  314.     compare method and the getSortKey(String, int, int) version of the
  315.     getSortKey method. A recent change to String.substring makes the substring
  316.     operation efficient. Users can use String.substring to specify a substring
  317.     rather than requiring methods to provide substring variants. Slimming the
  318.     API makes it easier to learn.
  319.     
  320.     Changed the type of public constants from byte to int.  Changed the
  321.     getStrength and getDecomposition methods to return int instead of byte.
  322.     Changed the setStrength and setDecomposition methods to accept int
  323.     arguments instead of byte.  Although the byte type provides a small amount
  324.     of type safety, using ints for constants is more in keeping with the rest
  325.     of the JDK.  The affected constants are:
  326.     
  327.      byte PRIMARY = 0;                 ==>    int PRIMARY = 0;                
  328.      byte SECONDARY = 1;               ==>    int SECONDARY = 1;              
  329.      byte TERTIARY = 2;                ==>    int TERTIARY = 2;               
  330.      byte IDENTICAL = 3;               ==>    int IDENTICAL = 3;              
  331.      byte NO_DECOMPOSITION = 0;        ==>    int NO_DECOMPOSITION = 0;       
  332.      byte CANONICAL_DECOMPOSITION = 1; ==>    int CANONICAL_DECOMPOSITION = 1;
  333.      byte FULL_DECOMPOSITION = 2;      ==>    int FULL_DECOMPOSITION = 2;     
  334.     
  335.     Removed the getDisplayName methods.  These returned the same result as
  336.     the corresponding Locale.getDisplayName method calls.  Until we have more
  337.     useful data, its better not to have these methods in the API.
  338.     
  339.     Provided a concrete equals method.  This allows sub-classes to correctly
  340.     implement the equals method.
  341.     
  342.     Renamed getSortKey method to getCollationKey.  See the change description
  343.     for getSortKey.
  344.     
  345.     Renamed getDefault methods to getInstance.  This follows new naming pattern
  346.     for factory methods.
  347.  
  348. ____________
  349. TEXT CHANGES - CollatedString
  350.  
  351.     Removed this class.  Its purpose was to associate a String with its
  352.     CollationKey. CollationKey has been changed retain a reference to the 
  353.     String it was generated from.  This allows us to reduce the size of the 
  354.     API.
  355.  
  356. ____________
  357. TEXT CHANGES - CollationElementIterator
  358.  
  359.     Removed the public constructor. CollationElementIterators are created by
  360.     RuleBasedCollator objects.  This was expressed by handing a
  361.     RuleBasedCollator object to the constructor.  This connection is more
  362.     obvious if the CollationElementIterator can only be created by a factory
  363.     method on RuleBasedCollator.
  364.  
  365.     Made the values returned by the next method directly comparable.  This is
  366.     not an API change but a semantic change for the next method.
  367.     
  368. ____________
  369. TEXT CHANGES - DateFormat
  370.  
  371.     Made the constructor protected.  DateFormat is an abstract class so it
  372.     doesn't need a public constructor.
  373.     
  374.     Removed the getDisplayName methods.  These returned the same result as
  375.     the corresponding Locale.getDisplayName method calls.  Until we have more
  376.     useful data, its better not to have these methods in the API.
  377.     
  378.     Added a style called MEDIUM that does what DEFAULT does now. For this
  379.     release, MEDIUM and DEFAULT have the same effect.  In future, the meaning 
  380.     of DEFAULT will be determined from the locale data. This is a more 
  381.     logical organization of the style choices.
  382.     
  383.     Changed the format methods to take a FieldPosition rather than a
  384.     FormatStatus argument. See the change description for FormatStatus.
  385.     
  386.     Changed the parse and parseObject methods to take a ParsePosition rather
  387.     than a ParseStatus argument. See the change description for ParseStatus.
  388.     
  389.     Renamed the getTimeFormat methods to getTimeInstance.  Renamed the
  390.     getDateFormat methods to getDateInstance.  Renamed the getDateTimeFormat
  391.     methods to getDateTimeInstance.  This follows new naming pattern
  392.     for factory methods.
  393.     
  394.     Added a getInstance() factory method that does the same thing as
  395.     getDateTimeFormat(SHORT,SHORT) previously did. This follows the pattern 
  396.     for factories which provides for a getInstance() that returns a default 
  397.     value to be always available.
  398.     
  399.     Renamed getValidationMode to isLenient.  Renamed setValidationMode to
  400.     setLenient. These names are more descriptive.
  401.     
  402.     Change the type of public constants from byte to int.  Although the byte
  403.     type provides a small amount of type safety, using ints for constants is
  404.     more in keeping with the rest of the JDK. Also rename constants to follow
  405.     the naming convention uses by JDK.  The results are:
  406.     
  407.      byte ERA_FIELD = 0;               ==> int ERA_FIELD = 0;
  408.      byte YEAR_FIELD = 1;              ==> int YEAR_FIELD = 1;
  409.      byte MONTH_FIELD = 2;             ==> int MONTH_FIELD = 2;
  410.      byte DATE_FIELD = 3;              ==> int DATE_FIELD = 3;
  411.      byte HOUROFDAY1_FIELD = 4;        ==> int HOUR_OF_DAY1_FIELD = 4;
  412.      byte HOUROFDAY0_FIELD = 5;        ==> int HOUR_OF_DAY0_FIELD = 5;
  413.      byte MINUTE_FIELD = 6;            ==> int MINUTE_FIELD = 6;
  414.      byte SECOND_FIELD = 7;            ==> int SECOND_FIELD = 7;
  415.      byte MILLISECOND_FIELD = 8;       ==> int MILLISECOND_FIELD = 8;
  416.      byte DAYOFWEEK_FIELD = 9;         ==> int DAY_OF_WEEK_FIELD = 9;
  417.      byte DAYOFYEAR_FIELD = 10;        ==> int DAY_OF_YEAR_FIELD = 10;
  418.      byte DAYOFWEEKINMONTH_FIELD = 11; ==> int DAY_OF_WEEK_IN_MONTH_FIELD = 11;
  419.      byte WEEKOFYEAR_FIELD = 12;       ==> int WEEK_OF_YEAR_FIELD = 12;
  420.      byte WEEKOFMONTH_FIELD = 13;      ==> int WEEK_OF_MONTH_FIELD = 13;
  421.      byte AMPM_FIELD = 14;             ==> int AM_PM_FIELD = 14;
  422.      byte HOUR1_FIELD = 15;            ==> int HOUR1_FIELD = 15;
  423.      byte HOUR0_FIELD = 16;            ==> int HOUR0_FIELD = 16;
  424.      byte TIMEZONE_FIELD = 17;         ==> int TIMEZONE_FIELD = 17;
  425.     
  426. ____________
  427. TEXT CHANGES - DateFormatData
  428.  
  429.     Renamed class to DateFormatSymbols.  This makes its purpose as a set of
  430.     strings and symbols to be used in formatting clearer.
  431.     
  432.     Removed the millisPerHour protected field.  This was not an appropriate
  433.     field in a collection of formatting symbols.
  434.     
  435.     Renamed getAmpms to getAmPmStrings.  Renamed setAmpms to setAmPmStrings. 
  436.     The new names follow the capitalization standard and are clearer.
  437.     
  438.     Removed methods useLocalizedPattern and setPatternLocalized.  This
  439.     functionality can be obtained through the toLocalizedPattern and
  440.     applyLocalizedPattern methods of SimpleDateFormat. These methods were not
  441.     appropriate in a collection of formatting symbols.
  442.     
  443. ____________
  444. TEXT CHANGES - DecimalFormat
  445.  
  446.     Renamed getThousandsInterval and setThousandsInterval methods to
  447.     getGroupingSize and setGroupingSize.  The new names are clearer.
  448.     
  449.     Renamed getFactor and setFactor methods to getMultiplier and setMultiplier.
  450.     The new names are clearer.
  451.     
  452.     Changed the constructor that takes a NumberFormatData to use a
  453.     DecimalFormatSymbols object instead. See the change description for
  454.     NumberFormatData. 
  455.     
  456.     Added a constructor that takes just a String and figures out the correct
  457.     DecimalFormatSymbols for the default locale.  This fills in the telescope
  458.     pattern for constructors.
  459.     
  460.     Renamed getPattern method to toPattern. Also removed the boolean argument
  461.     and instead added a toLocalizedPattern method. The new name better
  462.     reflects the fact that there is no "pattern" property, but rather a
  463.     pattern string is constructed that matches the current state of the
  464.     DecimalFormat object. Splitting the method into two allows many users to
  465.     ignore the existence of toLocalizedPattern.
  466.     
  467.     Renamed setPattern method to applyPattern. Also removed the boolean 
  468.     argument and instead added an applyLocalizedPattern method. The new 
  469.     name better reflects the fact that there is no "pattern" property, 
  470.     but rather a pattern string is used to set the state of the DecimalFormat 
  471.     object. Splitting the method into two allows many users to ignore the 
  472.     existence of applyLocalizedPattern.
  473.     
  474.     Removed the "*" and "_" characters from the pattern syntax.  This is not
  475.     strictly an api change but it is a semantic change.  These characters were
  476.     of limited use the way they were implemented.
  477.     
  478.     Changed the format methods to take a FieldPosition rather than a
  479.     FormatStatus argument. See the change description for FormatStatus.
  480.     
  481.     Changed the parse method to take a ParsePosition rather than a
  482.     ParseStatus argument. See the change description for ParseStatus.
  483.     
  484.     Renamed getNumberFormatData to getDecimalFormatSymbols and changed its
  485.     return type to DecimalFormatSymbols.  Renamed setNumberFormatData to
  486.     setDecimalFormatSymbols and changed its argument type to
  487.     DecimalFormatSymbols.  See the change description for NumberFormatData.
  488.     
  489. ____________
  490. TEXT CHANGES - Format
  491.     
  492.     Changed the format method to take a FieldPosition rather than a 
  493.     FormatStatus argument. See the change description for FormatStatus.
  494.     
  495.     Changed the parseObject method to take a ParsePosition rather than a
  496.     ParseStatus argument. See the change description for ParseStatus.
  497.  
  498. ____________
  499. TEXT CHANGES - FormatException
  500.  
  501.     Renamed class to ParseException.  This better reflects its purpose.
  502.     
  503.     Removed the no argument constructor.  This constructor was not useful.
  504.  
  505. ____________
  506. TEXT CHANGES - FormatStatus
  507.  
  508.     Renamed class to FieldPosition.  This better reflects its purpose as an
  509.     object which describes where sub-fields are located in a formatted string.
  510.     
  511.     Replaced public integer fields with getter methods.  Adjusted names to
  512.     match pattern for indicating ranges in text.  The result:
  513.     
  514.      int alignField   ==> int getField()
  515.      int alignStart   ==> int getBeginIndex()
  516.      int alignEnd     ==> int getEndIndex()
  517.     
  518.     Replaced no argument constructor with a constructor that sets the field.
  519.     A field value must always be set so this prevents invalid objects.  
  520.     It is also more convenient than doing it in two steps.
  521.     
  522. ____________
  523. TEXT CHANGES - MessageFormat
  524.  
  525.     Redesigned the syntax for message patterns to allow inlining of other
  526.     pattern strings, such as date patterns, number patterns, choice patterns
  527.     etc. This is not itself an API change but is a big semantic difference.
  528.     This change allows complete message formats to be created in fewer steps.
  529.  
  530.     Removed the constructor that took a String and a Format array.  This was
  531.     not needed with the new inline pattern syntax.
  532.  
  533.     Added a setFormat method which allows a single format to be set at a time
  534.     rather than requiring all formats to be specified like the setFormats
  535.     method. This is more convenient given the inline pattern syntax.
  536.  
  537.     Removed the format method that took a String, a Format array and an Object
  538.     array.  It was not necessary with the new inline pattern syntax.
  539.  
  540.     Changed the parse method that takes a single String argument to return an
  541.     array of Objects rather than a single Object.  This makes more sense given
  542.     the fact that a message may have many objects embedded in it.
  543.     
  544.     Changed the format methods to take a FieldPosition rather than a
  545.     FormatStatus argument. See the change description for FormatStatus.
  546.     
  547.     Changed the parse method to take a ParsePosition rather than a ParseStatus
  548.     argument. See the change description for ParseStatus.
  549.     
  550.     Renamed getPattern method to toPattern. The new name better reflects the
  551.     fact that there is no "pattern" property. Rather a pattern string is
  552.     constructed that matches the current state of the MessageFormat object.
  553.     
  554.     Renamed setPattern method to applyPattern. The new name better reflects
  555.     the fact that there is no "pattern" property. Rather a pattern string is
  556.     used to set the state of the MessageFormat object.
  557.  
  558.     Added setLocale and getLocale methods.
  559.  
  560. ____________
  561. TEXT CHANGES - NumberFormat
  562.  
  563.     Renamed getDefaultCurrency to getCurrencyInstance.  Renamed
  564.     getDefaultPercent to getPercentInstance.  Added a getNumberInstance
  565.     factory.  Rename getDefault to getInstance.  This follows the naming
  566.     pattern for factories.
  567.     
  568.     Removed getCurrencySymbol and getIntlCurrencySymbol methods. These will be
  569.     added to a more appropriate class in a future release.
  570.     
  571.     In the methods called {get|set}{Minimum|Maximum}{Integer|Decimal}Count,
  572.     rename the word Count to Digits and the word Decimal to Fraction.  These
  573.     names are clearer.
  574.     
  575.     Remove the methods isDecimalUsedWithInteger and
  576.     setDecimalUsedWithInteger. These methods are now found in DecimalFormat
  577.     under the names isDecimalSeparatorAlwaysShown
  578.     setDecimalSeparatorAlwaysShown.
  579.     
  580.     Renamed setIntegerOnly to setParseIntegerOnly. Renamed isIntegerOnly to
  581.     isParseIntegerOnly.
  582.     
  583.     Renamed {is|set}ThousandsUsed to {is|set}GroupingUsed.
  584.     
  585.     Removed the getDisplayName methods.  These returned the same result as
  586.     the corresponding Locale.getDisplayName method calls.  Until we have more
  587.     useful data, its better not to have these methods in the API.
  588.     
  589.     Renamed DECIMAL_FIELD to FRACTION_FIELD. Also changed its type from byte
  590.     to int. This name is more general. Use of ints as constants is standard
  591.     practice.
  592.     
  593.     Removed NUMERATOR_FIELD, DENOMINATOR_FIELD and EXPONENT_FIELD. This
  594.     functionality was not supported in this release.
  595.  
  596. ____________
  597. TEXT CHANGES - NumberFormatData
  598.  
  599.     Renamed class DecimalFormatSymbols. This makes its purpose as a set of
  600.     strings and symbols to be used in formatting clearer.
  601.     
  602.     Added a default constructor which constructs an object suitable for the
  603.     default locale.  Added a constructor which takes a locale.  These follow 
  604.     the pattern set by DateFormatSymbols.
  605.     
  606.     Removed starDigit, spaceDigit and exponential fields.  This functionality 
  607.     is not being supported by DecimalFormat.
  608.     
  609.     Changed public fields to getter/setter methods.  Adjusted the names of the
  610.     methods for clarity.  The results are:
  611.     
  612.      char zeroDigit;         ==> getZeroDigit(), setZeroDigit()        
  613.      char thousandsSign;     ==> getGroupingSeparator(), setGroupingSeparator()
  614.      char decimalSign;       ==> getDecimalSeparator(), setDecimalSeparator()
  615.      char millePercent;      ==> getPerMill(), setPerMill()               
  616.      char percent;           ==> getPercent(), setPercent()               
  617.      char digit;             ==> getDigit(), setDigit()               
  618.      char separator;         ==> getPatternSeparator(), setPatternSeparator() 
  619.      java.lang.String infinity; ==> getInfinity(), setInfinity()    
  620.      java.lang.String nan;   ==> getNaN(), setNaN()
  621.      char minusSign;         ==> getMinusSign(), setMinusSign()    
  622.     
  623.     Removed the static final char fields.  These were not appropriate for a
  624.     collection of locale specific number formatting fields.  They were also 
  625.     of little use outside the implementation of DecimalFormat. The removed 
  626.     fields are:
  627.     
  628.      static final char patternZeroDigit = 48;
  629.      static final char patternThousandsSign =
  630.      static final char patternDecimalSign = 4
  631.      static final char patternMillePercent = 
  632.      static final char patternPercent = 37;  
  633.      static final char patternDigit = 35;    
  634.      static final char patternStarDigit = 42;
  635.      static final char patternSpaceDigit = 95
  636.      static final char patternSeparator = 59;
  637.  
  638. ____________
  639. TEXT CHANGES - ParseStatus
  640.  
  641.     Renamed class ParsePosition.  This better reflects its purpose as an object
  642.     which shows where parsing starts and stops.
  643.     
  644.     Removed no argument constructor. This was redundant and of no real
  645.     convenience.
  646.     
  647.     Changed public field startAt to a getter/setter method pair.  Also
  648.     adjusted names of the methods to suit the naming pattern for indicating
  649.     characters in a String.  The results:
  650.     
  651.       startAt   ==> getIndex(), setIndex()
  652.  
  653. ____________
  654. TEXT CHANGES - SimpleDateFormat
  655.  
  656.     Changed the format method to take a FieldPosition rather than a 
  657.     FormatStatus argument. See the change description for FormatStatus.
  658.     
  659.     Changed the parse method to take a ParsePosition rather than a ParseStatus
  660.     argument. See the change description for ParseStatus.
  661.     
  662.     Changed the constructor which took a DateFormatData object to use a
  663.     DateFormatSymbols object instead.  See the change description for
  664.     DateFormatData.
  665.     
  666.     Renamed getDateFormatData and setDateFormatData to getDateFormatSymbols 
  667.     and setDateFormatSymbols. See the change description for DateFormatData.
  668.     
  669.     Renamed getPattern method to toPattern. Also removed the boolean argument 
  670.     and instead added a toLocalizedPattern method. The new name better 
  671.     reflects the fact that there is no "pattern" property, but rather a 
  672.     pattern string is constructed that matches the current state of the 
  673.     DecimalFormat object. Splitting the method into two allows many users 
  674.     to ignore the existence of toLocalizedPattern.
  675.     
  676.     Renamed setPattern method to applyPattern. Also removed the boolean 
  677.     argument and instead added an applyLocalizedPattern method. The new 
  678.     name better reflects the fact that there is no "pattern" property, but 
  679.     rather a pattern string is used to set the state of the DecimalFormat 
  680.     object. Splitting the method into two allows many users to ignore the 
  681.     existence of applyLocalizedPattern.
  682.  
  683.     Added a convenience no argument constructor.
  684.  
  685. ____________
  686. TEXT CHANGES - SortKey
  687.  
  688.     Renamed class CollationKey.  This keeps the terminology consistent with
  689.     the other collation classes.
  690.     
  691.     Added getSourceString method.  This returns the string that this 
  692.     CollationKey represents. This allows the removal of the CollatedString 
  693.     class.
  694.     
  695.     Added a toByteArray method that returns a byte[] containing the key. 
  696.     
  697.     Changed compareTo method to return int rather than byte.  This follows the
  698.     pattern set by java.lang.String.compareTo.
  699.     
  700. ____________
  701. TEXT CHANGES - StringCharacterIterator
  702.  
  703.     Added the following convenience constructor:
  704.     
  705.       public StringCharacterIterator(String text, int begin, int end, int pos) 
  706.     
  707.     Renamed startIndex method to getBeginIndex.  Renamed endIndex method to
  708.     getEndIndex. These names are consistent with the pattern for indicating 
  709.     ranges in strings.
  710.     
  711.     Removed the getText method.  See the change description for 
  712.     CharacterIterator.
  713.  
  714. ____________
  715. TEXT CHANGES - TableCollation
  716.  
  717.     Renamed class RuleBasedCollator.  It was not clear from the old name 
  718.     whether this class actually did collation or simply represented a set 
  719.     of collation rules.  The new name makes it clear that the class performs 
  720.     string comparisons. It also avoids the impression that this class 
  721.     collates tables.
  722.     
  723.     Renamed getSortKey method to getCollationKey.  See the change description 
  724.     for SortKey. 
  725.     
  726.     Removed the getSortKey method that operated on a substring of a given 
  727.     String.  A recent change to String.substring makes the substring 
  728.     operation efficient. Users can use String.substring to specify a 
  729.     substring rather than requiring methods to provide substring variants. 
  730.     Slimming the API makes it easier to learn.
  731.     
  732.     Removed the compare method that operated on a substring of a given String. 
  733.     A recent change to String.substring makes the substring operation
  734.     efficient. Users can use String.substring to specify a substring rather 
  735.     than requiring methods to provide substring variants. Slimming the API 
  736.     makes it easier to learn.
  737.     
  738.     Changed compare to return an int value instead of a byte value.  See 
  739.     the change description for Collation.
  740.     
  741. ____________
  742. TEXT CHANGES - TextBoundary
  743.  
  744.     Renamed class to BreakIterator.  This more clearly reflects its purpose.
  745.     
  746.     Renamed method nthFromCurrent to next(int). This is a less awkward name.
  747.     
  748.     Renamed method nextAfter to following.  This is a less awkward name.
  749.     
  750.     Changed the return type of getText to CharacterIterator.  Since
  751.     BreakIterator works in terms of a CharacterIterator it didn't make sense
  752.     to return a String.
  753.     
  754.     Renamed getWorkBreak methods to getWordInstance.  Renamed getLineBreak
  755.     methods to getLineInstance. Renamed getCharacterBreak methods to
  756.     getCharacterInstance. Renamed getSentenceBreak methods to
  757.     getSentenceInstance.  This follows the naming pattern for factory methods.
  758.  
  759. ____________
  760. UTIL CHANGES - Calendar
  761.  
  762.     Changed the type of the public constants from byte to int.  Changed the
  763.     corresponding methods to accept and return ints instead of bytes.  and
  764.     getDecomposition methods to return int instead of byte.  Although the byte
  765.     type provides a small amount of type safety, using ints for constants is 
  766.     more in keeping with the rest of the JDK.  The results are:
  767.   
  768.      byte ERA = 0;                  ==>   int ERA = 0;                  
  769.      byte YEAR = 1;                 ==>   int YEAR = 1;                 
  770.      byte MONTH = 2;                ==>   int MONTH = 2;                
  771.      byte WEEKOFYEAR = 3;           ==>   int WEEK_OF_YEAR = 3;         
  772.      byte WEEKOFMONTH = 4;          ==>   int WEEK_OF_MONTH = 4;        
  773.      byte DATE = 5;                 ==>   int DATE = 5;                 
  774.      byte DAYOFMONTH = 5;           ==>   int DAY_OF_MONTH = 5;         
  775.      byte DAYOFYEAR = 6;            ==>   int DAY_OF_YEAR = 6;          
  776.      byte DAYOFWEEK = 7;            ==>   int DAY_OF_WEEK = 7;          
  777.      byte DAYOFWEEKINMONTH = 8;     ==>   int DAY_OF_WEEK_IN_MONTH = 8; 
  778.      byte AMPM = 9;                 ==>   int AM_PM = 9;                
  779.      byte HOUR = 10;                ==>   int HOUR = 10;                
  780.      byte HOUROFDAY = 11;           ==>   int HOUR_OF_DAY = 11;         
  781.      byte MINUTE = 12;              ==>   int MINUTE = 12;              
  782.      byte SECOND = 13;              ==>   int SECOND = 13;              
  783.      byte MILLISECOND = 14;         ==>   int MILLISECOND = 14;         
  784.      byte ZONEOFFSET = 15;          ==>   int ZONE_OFFSET = 15;         
  785.      byte DSTOFFSET = 16;           ==>   int DST_OFFSET = 16;          
  786.      byte FIELDCOUNT = 17;          ==>   int FIELD_COUNT = 17;         
  787.                                            
  788.      int get(byte);                 ==>   int get(int);
  789.      set(byte,int);                 ==>   void set(int,int);
  790.      void clear(byte);              ==>   void clear(int);
  791.      void add(byte,int);            ==>   void add(int,int);     
  792.      void roll(byte,boolean);       ==>   void roll(int,boolean);
  793.      void setFirstDayOfWeek(byte);  ==>   void setFirstDayOfWeek(int);
  794.      void setMinimalDaysInFirstWeek(byte);
  795.                                     ==>   void setMinimalDaysInFirstWeek(int);
  796.      int getMinimum(byte);          ==>   int getMinimum(int);         
  797.      int getMaximum(byte);          ==>   int getMaximum(int);         
  798.      int getGreatestMinimum(byte);  ==>   int getGreatestMinimum(int); 
  799.      int getLeastMaximum(byte);     ==>   int getLeastMaximum(int);    
  800.                                                
  801.     
  802.     Renamed getValidationMode to isLenient.  Renamed setValidationMode to
  803.     setLenient. These names are more descriptive.
  804.     
  805.     Renamed the getDefault methods to getInstance.  This is in keeping with the
  806.     pattern for naming factory methods.
  807.  
  808. ____________
  809. UTIL CHANGES - GregorianCalendar
  810.  
  811.     Changed the type of the public constants from byte to int.  Changed the
  812.     corresponding methods to accept and return ints instead of bytes.  and
  813.     getDecomposition methods to return int instead of byte.  Although the byte
  814.     type provides a small amount of type safety, using ints for constants 
  815.     is more in keeping with the rest of the JDK.  The results are:
  816.      
  817.      final byte AD = 0;           ==>      final int AD = 0; 
  818.      final byte BC = 1;           ==>      final int BC = 1; 
  819.     
  820.      void add(byte,int);          ==>      void add(int,int);          
  821.      void roll(byte,boolean);     ==>      void roll(int,boolean);       
  822.      int getMinimum(byte);        ==>      int getMinimum(int);          
  823.      int getMaximum(byte);        ==>      int getMaximum(int);          
  824.      int getGreatestMinimum(byte);==>      int getGreatestMinimum(int);  
  825.      int getLeastMaximum(byte);   ==>      int getLeastMaximum(int);     
  826.                                      
  827. ____________
  828. UTIL CHANGES - ResourceBundle
  829.  
  830.     Renamed getResourceBundle methods to getBundle.  The name
  831.     getResourceBundle was too long and overly redundant.  The new name is not
  832.     in keeping with the naming pattern for factory methods.  This is because
  833.     the name "getInstance" is being reserved for a future addition to the
  834.     resource bundle classes.
  835.     
  836. __________
  837. AWT CHANGE -  Compiling programs that use old AWT API now produces
  838.               deprecation warnings
  839.  
  840.     In the beta versions of 1.1, the deprecated methods in the AWT were
  841.     marked with simple "DEPRECATED" strings in the method's javadoc
  842.     comment.  For the final release we have added the appropriate
  843.     "@deprecated" tags to those methods so that you can use the
  844.     appropriate compiler option to generate warnings that make it
  845.     easier for you to convert your programs when you desire to do so.
  846.  
  847.     The document at the following URL describes how to convert to the
  848.     1.1 AWT API.  It also links to a document that lists every deprecated
  849.     method and its 1.1 substitute.
  850.  
  851.     http://java.sun.com/products/JDK/1.1/docs/guide/awt/HowToUpgrade.html
  852.  
  853.     RATIONALE:
  854.  
  855.     The bulk of the AWT deprecations are a result of migrating the AWT
  856.     towards JavaBeans compliance.  In particular, the two areas which
  857.     required a significant number of deprecations were:
  858.  
  859.     - Properties (location, size, visibility, etc.)
  860.       In order for introspection to be able to programmatically extract
  861.       properties from AWT components, it was necessary to change the
  862.       names of various methods to the JavaBeans getFoo/setFoo pattern.
  863.     
  864.     - New event model
  865.       JavaBeans and the AWT have defined a new delegation-based event
  866.       model for 1.1 which required significant changes to the event
  867.       handling API.
  868.     
  869.     Finally, a small set of deprecated methods were changed to enhance
  870.     the learnability and consistency of the toolkit API.
  871.  
  872. __________
  873. AWT CHANGE -  Z-ordering changed back to 1.0.2 order
  874.  
  875.     For beta3, the Z-ordering for children in Container instances was
  876.     defined in the documentation to be "back to front".  Because this
  877.     was contrary to the default Z-ordering which existed in 1.0.2 (and
  878.     the beta implementation), for FCS we have corrected the Z-ordering
  879.     specification in containers to be "front to back".
  880.  
  881. __________
  882. AWT CHANGE -  Changed names of newly-added APIs:
  883.  
  884.     The following APIs have been renamed ( from old name => to new name ):
  885.  
  886.      AverageScaleFilter    =>    AreaAveragingScaleFilter
  887.      createScaledImage(...)    =>    getScaledInstance(...)
  888.      SCALE_AVERAGE        =>    SCALE_AREA_AVERAGING
  889.  
  890.     RATIONALE:
  891.     The method name was changed to "getScaledInstance(...)" to be
  892.     consistent with the overall philosophy within the Java API where
  893.     factories and derivative constructors should follow the naming
  894.     convention of
  895.  
  896.         get<Flavor>Instance(...arguments...)
  897.  
  898.     The term "Average" was not descriptive of the algorithm applied by
  899.     the default smooth scaling filter, so the name of this filter and
  900.     its algorithm were changed to "AreaAveraging" to indicate what
  901.     quantity was being averaged.
  902.  
  903. __________
  904. AWT CHANGE - Changed dispatchEvent() method and added new method
  905.              dispatchEventImpl()
  906.  
  907.     The codepath in dispatchEvent() really must be executed for event
  908.     mechanics to work properly in the AWT (hence we made it 
  909.     package-private).  We moved the implementation to a new
  910.     package-private method (dispatchEventImpl()) and then 
  911.     changed dispatchEvent() to be "public final" and have it
  912.     call dispatchEventImpl() internally.
  913.  
  914.     RATIONALE:
  915.     We have deprecated the 1.0 postEvent()/deliverEvent() methods,
  916.     however the method that replaces those (dispatchEvent()) is
  917.     currently package-private.  This left no options for folks
  918.     porting to the new event model.
  919.  
  920. __________
  921. AWT CHANGE - Changed capitalization of getId() to getID() in
  922.     java.awt.AWTEvent
  923.  
  924.     Changed the method name to getID() and provided a deprecated version
  925.     for compatibility with the beta versions.
  926.  
  927.     RATIONALE:
  928.     java.awt.AWTEvent.getID() is named in a manner inconsistent with 
  929.     the equivalent methods in other classes:
  930.     java.awt.MediaTracker.getID()
  931.     java.util.TimeZone.getID()
  932.     sun.rmi.registry.RegistryImpl.getID()
  933.     sun.rmi.transport.DGCImpl.getID()
  934.  
  935.     Developers have had trouble because they expected the naming to 
  936.     be consistent.  This fixes bug 4027793.
  937.  
  938. __________
  939. AWT CHANGE - Changed EventQueue to be non-system-specific
  940.  
  941.   The following changes were made to EventQueue:
  942.   
  943.   1)  Moved the static getEventQueue() method out of EventQueue
  944.       and instead put it in Toolkit with the name "getSystemEventQueue()".
  945.       Left the security check in that method, so that applets 
  946.       cannot get access to the system queue instance (see also #3).
  947.   
  948.   2)  Added a public constructor to the EventQueue class such that
  949.       multiple instances of it can be created.  This will allow programs
  950.       to create and use the queue generically, as well as enable browser
  951.       vendors to implement a queue/dispatch-thread-per-applet model.
  952.   
  953.   3)  Removed the overriding checkAwtEventQueueAccess() method in the 
  954.       AppletSecurityManager such that it will always default to
  955.       invoking lang.SecurityManager.checkAwtEventQueueAccess()
  956.       and will *always* throw a security exception if an applet tries
  957.       to get a handle on the system event queue.
  958.   
  959.   4)  Modified the EventQueue documentation so that it's clear that
  960.       the class is very generic.  All references to a "system
  961.       EventQueue" have been eliminated.
  962.  
  963.     RATIONALE:
  964.     This allows the implementation of one dispatch thread per applet.
  965.     It also provides design flexibility for the future.
  966.  
  967. __________
  968. AWT CHANGE - Removed EventSource class
  969.  
  970.     Removed this class because it has no relation to the new event model. 
  971.  
  972. __________
  973. AWT CHANGE - Changed API for delivery of window-open and 
  974.              window-closed events
  975.  
  976.     Moved the window event API (addWindowListener,removeWindowListener,
  977.     etc.) from Dialog and Frame to Window (their superclass) so
  978.     that the code is there in one place.  
  979.  
  980.     RATIONALE:
  981.     Centralizing the code eliminates duplication and makes it easier 
  982.     to maintain.
  983.  
  984. __________
  985. AWT CHANGE - Changed return type from Transferable.getTransferData
  986.  
  987.     Transferable.getTransferData returns class BufferedInputStream.
  988.  
  989. __________
  990. AWT CHANGE - MenuShortcut class no longer extends java.awt.Event.
  991.  
  992. __________
  993. AWT CHANGE - Changed button modifier mask values in InputEvent:
  994.         BUTTON2_MASK is now equivalent to ALT_MASK 
  995.             BUTTON3_MASK is now equivalent to META_MASK
  996.  
  997.     RATIONALE:
  998.     A couple of mask constants were incorrectly defined in the
  999.     InputEvent class.  These event masks are new in JDK1.1.
  1000.     
  1001.     This change will ensure that programs that depend on seeing the
  1002.     BUTTON1_MASK and BUTTON2_MASK will continue to work properly on
  1003.     platforms that have 1 and 2 button mice (because Alt/Meta can be
  1004.     used to generate these masks on those systems).
  1005.  
  1006.     This fixes bug 4029159: Button2/Button3 masks should have same 
  1007.     value as Alt/Meta in InputEvent
  1008.     
  1009. __________
  1010. AWT CHANGE - Change to serialization of AWT components
  1011.  
  1012.     Made a systematic change to the way JDK1.1 AWT does serialization.
  1013.  
  1014.     RATIONALE:
  1015.     This change corrects bug #4027305, and provides more carefully 
  1016.     thought-out and rational behaviour for AWT serialization in general. 
  1017.  
  1018.     These changes enable customers to use serialization to store
  1019.     Java Beans (in general) and to enable AWT implementations 
  1020.     to correctly interoperate between vendors.
  1021.  
  1022.     Implications for developers:
  1023.   
  1024.       - Saving graphs of AWT objects will now work, even if an object
  1025.         has more than one listener.
  1026.   
  1027.       - If an AWT object has listeners that are marked serializable, they
  1028.         will be saved and restored automatically, such as beans 
  1029.         interconnected with and saved to a file with the BeanBox. 
  1030.         Note that the BeanBox always code-generates serializable 
  1031.         listener implementations.
  1032.       
  1033.       - If an AWT object has listeners that aren't marked serializable
  1034.         they will be dropped at writeObject() time.
  1035.   
  1036.       - Developers will need, as always, to consider the implications of
  1037.         making an object serializable.  One idiom to watch out for is 
  1038.         this:
  1039.   
  1040.         import java.awt.*;
  1041.         import java.awt.event.*;
  1042.         import java.io.Serializable;
  1043.   
  1044.         class MyApp implements ActionListener, Serializable
  1045.         {
  1046.           BigObjectThatShouldNotBeSeralizedWithAButton bigOne;
  1047.           Button aButton = new Button();
  1048.   
  1049.           MyApp()
  1050.           {
  1051.              // Oops, now aButton has a listener with a 
  1052.              // reference to bigOne!
  1053.              aButton.addActionListener(this);    
  1054.           }
  1055.   
  1056.           public void actionPerformed(ActionEvent e)
  1057.           {
  1058.             System.out.println("Hello There");
  1059.           }
  1060.         }
  1061.   
  1062.     In this example, serializing aButton by itself will cause MyApp and
  1063.     everything it refers to to be serialized as well.  The problem
  1064.     is that the listener is serializable by coincidence, not by design.
  1065.     To separate the decisions about MyApp and the ActionListener being 
  1066.     serializable one can use an inner (nested) class, for example:
  1067.   
  1068.     import java.awt.*;
  1069.     import java.awt.event.*;
  1070.     import java.io.Serializable;
  1071.   
  1072.     class MyApp java.io.Serializable
  1073.     {
  1074.       BigObjectThatShouldNotBeSeralizedWithAButton bigOne;
  1075.       Button aButton = new Button();
  1076.   
  1077.       class MyActionListener implements ActionListener
  1078.       {
  1079.         public void actionPerformed(ActionEvent e)
  1080.         {
  1081.       System.out.println("Hello There");
  1082.         }
  1083.       }
  1084.   
  1085.       MyApp()
  1086.       {
  1087.          aButton.addActionListener(new MyActionListener());
  1088.       }
  1089.     }
  1090.  
  1091. __________
  1092. AWT CHANGE - Added setKeyChar() method to KeyEvent
  1093.  
  1094.     KeyEvent had a setKeyCode() already. This new method was needed
  1095.     to copy any changes a 1.0 style program may have made
  1096.     to an Event "key".  This fix ensures that all chars work
  1097.     properly in TextFields, like hitting <return> in HotJava's URL field.
  1098.  
  1099. __________
  1100. AWT CHANGE - Changed PaintEvent class to use a rectangle for damaged area
  1101.  
  1102.     Replaced PaintEvent's "Graphics" property with a Rectangle 
  1103.     representing a damaged area instead.  
  1104.  
  1105.     RATIONALE:
  1106.     Although the PaintEvent class is public, its use in AWT 
  1107.     is completely private -- it is used to trigger calls to paint(), 
  1108.     but programs never explicitly see the event object at all.
  1109.  
  1110. __________
  1111. AWT CHANGE - Defined a new constant in AWTEvent:
  1112.         RESERVED_ID_MAX
  1113.  
  1114.     This new constant is the maximum value of any AWT-defined event ID.
  1115.     Programs that need to create their own event types should use
  1116.     an ID greater than this max ID, so that the event will be properly
  1117.     passed through the system.
  1118.  
  1119.     RATIONALE:
  1120.     This is part of the fix for a problem that prevented anyone from
  1121.     being able to create their own event type and send it to a
  1122.     component. 
  1123.  
  1124.     This fixes bug 4028353: eventEnabled returns false for all but 
  1125.     AWT events; can't send custom event types.
  1126.  
  1127. ____________
  1128. BEANS CHANGE - Improved handling of beans that are applets
  1129.  
  1130.     Changed Beans.instantiate to check if a newly created or deserialized
  1131.     bean is an Applet.  If so, it is given a minimal AppletStub and
  1132.     AppletContext and its init method is called.
  1133.  
  1134.     After developers have added a newly instantiated bean to an AWT
  1135.     container, they should check if it is an Applet and if so call
  1136.     Applet.start.
  1137.  
  1138.     Also, developers need to test "wanna-be" applet/beans against
  1139.     Beans.instantiate.
  1140.  
  1141. ____________
  1142. BEANS CHANGE - Serializable listener fix for Beans classes
  1143.  
  1144.     The java.beans package contains two utility classes, 
  1145.     PropertyChangeSupport and VetoableChangeSupport, that manage
  1146.     a list of event listeners.  The change was to make the way 
  1147.     these classes are serialized consistent with the AWT.
  1148.  
  1149.     RATIONALE
  1150.     In beta3 these two classes were inconsistent with the AWT,
  1151.     which meant there was no support for selectively saving and 
  1152.     restoring listeners marked serializable.  The changes are 
  1153.     all class private. 
  1154.  
  1155. _______________
  1156. SECURITY CHANGE - Key is now an interface
  1157.  
  1158.     Made Key an interface and updated relevant clients.  Removed all 
  1159.     implementation from Key to make it an interface. Moved its 
  1160.     implementation into sun.security.
  1161.  
  1162.     RATIONALE:
  1163.     Key as an interface is more flexible and easier to implement than 
  1164.     a mix of interfaces and classes.
  1165.  
  1166. _______________
  1167. SECURITY CHANGE - Changed names of factory methods
  1168.  
  1169.     Changed factory names from <Engine>.get<Engine> to get<Engine>.
  1170.  
  1171.     RATIONALE:
  1172.     Factory method names were MessageDigest.getMessageDigest, 
  1173.     Signature.getSignature, etc. A better naming scheme is Signature.get, 
  1174.     MessageDigest.get, etc. This is important when you start casting the 
  1175.     results to some fairly long interface names, for example:  
  1176.     DSAKeyGen keyGen = (DSAKeyGen)KeyGenerator.getKeyGenerator("DSA");
  1177.  
  1178. _______________
  1179. SECURITY CHANGE - Changed Provider SPI for java.security.Signature
  1180.     Initialization 
  1181.  
  1182.     The SPI is the Service Provider Interface, which Providers write to. 
  1183.     There currently are two providers: SUN and JSAFE.
  1184.  
  1185.     a) Changed the arguments to two initialization method in Signature
  1186.        from (byte[], String) to (Key)
  1187.     b) Made one method in key public.
  1188.     c) Added a small interface (no implementation): DSAPrivateKey
  1189.  
  1190.     Changed java.security.Signature and sun.security.provider.DSA.
  1191.  
  1192. _______________
  1193. SECURITY CHANGE- API changes to Signature, MessageDigest, and 
  1194.     KeyPairGenerator
  1195.  
  1196.     Signature
  1197.       public Signature get(String algorithm)     ->
  1198.       public Signature getInstance(String algorithm)
  1199.     
  1200.       public Signature get(String algorithm, String provider) ->
  1201.       public Signature getInstance(String algorithm, String provider)
  1202.  
  1203.     MessageDigest
  1204.       public MessageDigest get(String algorithm) ->
  1205.       public MessageDigest getInstance(String algorithm)
  1206.  
  1207.       public MessageDigest get(String algorithm, String provider) ->
  1208.       public MessageDigest getInstance(String algorithm, String provider)
  1209.  
  1210.     KeyPairGenerator
  1211.       public KeyPairGenerator get(String algorithm) ->
  1212.       public KeyPairGenerator getInstance(String algorithm)
  1213.     
  1214.       public KeyPairGenerator get(String algorithm, String provider) ->
  1215.       public KeyPairGenerator getInstance(String algorithm, String provider)
  1216.  
  1217. _______________
  1218. SECURITY CHANGE - Changed key generation API
  1219.  
  1220.     The change consisted of moving a set of existing methods from 
  1221.     Signature to a new KeyPairGenerator class.
  1222.  
  1223.     API change:
  1224.     a) Moved key generation calls from signature to a new
  1225.        KeyPairGenerator class
  1226.     b) Added a small DSAKeyPairGenerator interface, which specializes
  1227.        behavior for DSA key generation. 
  1228.  
  1229.     The change  consisted of moving 3 abstract API methods to a new class.
  1230.     - defined a KeyGenerator factory method (identical to
  1231.       Signature's).
  1232.     - added one line to ths sun.security.provider.DSA class.
  1233.     - added one line to ths sun.security.provider.Sun class.
  1234.     - updated API clients in JDK (there are two of them).
  1235.  
  1236.  
  1237.     RATIONALE:
  1238.     Customer feedback makes a strong case for moving the
  1239.     Signature class key generation calls into its own class. Key
  1240.     generation is currently implemented as part of the Signature
  1241.     class. While it provides a uniform, algorithm-independent
  1242.     key-generation semantics, it is hard to understand (and therefore to
  1243.     use). It has confused users both internally and externally.
  1244.   
  1245. __________
  1246. JAR CHANGE - Can now handle compressed JAR files in the CLASSPATH
  1247.  
  1248.     java.util.zip.ZipFile was enhanced so that it can now handle 
  1249.     compressed ZIP/JAR file entries. No changes to the API were made. 
  1250.     With this change, compressed JAR/ZIP files can now be handled
  1251.     by javac.
  1252.  
  1253.     Additionally, the runtime has also changed so that it can now
  1254.     handle compressed ZIP/JAR files that are specified in the CLASSPATH.
  1255.  
  1256. ___________
  1257. LANG CHANGE - Removed a constructor and two methods from java.lang.Throwable
  1258.  
  1259.     - Removed the Throwable(String, Object[]) constructor 
  1260.     - Removed the setArguments() method 
  1261.     - Removed the getArguments() method 
  1262.  
  1263.     RATIONALE:
  1264.     The arguments property was originally added to java.lang.Throwable for 
  1265.     use in the generation of localized messages.  This was deemed premature, 
  1266.     and so the property was removed in order to avoid tempting programmers 
  1267.     to use it for some other purpose.
  1268.  
  1269. _________
  1270. IO CHANGE - Deprecated constructor StreamTokenizer(InputStream)
  1271.  
  1272.     This fixed bug 4025998.
  1273.  
  1274.     RATIONALE:
  1275.     The StreamTokenizer(InputStream) constructor was not binary-compatible 
  1276.     with JDK 1.0.2.  This constructor was changed in JDK1.1 to convert 
  1277.     automatically from bytes to characters using the platform's default
  1278.     character encoding, but that change required buffering input data, 
  1279.     which breaks binary compatibility.  This change has been removed.
  1280.  
  1281. ____________________________
  1282. JAVA NATIVE INTERFACE CHANGE - Changed the names of VM initialization
  1283. and thread-attach structures
  1284.  
  1285.     Changed the JDK initialization structure name from JavaVMInitArgs to 
  1286.     JDK1_1InitArgs to make it clear that it is JDK1.1 specific.
  1287.  
  1288.     Similarly, ThreadAttachArgs has changed its name to JDK1_1AttachArgs.
  1289.  
  1290.     RATIONALE:
  1291.     When a native application uses the invocation API to start up
  1292.     the VM, it passes the VM an initialization structure. Since in
  1293.     general different VM implementations require different 
  1294.     initialization information (min/max heap size, native stack size,
  1295.     enable debugging, etc.), the JNI spec explicitly says
  1296.     that the contents of the structure vary among VM implementations.
  1297.     However, the JDK initialization structure, JavaVMInitArgs, gives 
  1298.     the wrong impression that it should work with other VMs. This has
  1299.     caused confusion on how to implement the JNI without conflicting
  1300.     with JDK's naming scheme.
  1301.  
  1302. ____________________________
  1303. JAVA NATIVE INTERFACE CHANGE - Changed NewStringUTF parameters
  1304.  
  1305.     Removed the length argument, strlen(s, from NewStringUTF().  The
  1306.     signature for this method is now:
  1307.  
  1308.     jstring NewStringUTF(JNIEnv *env, const char *s);
  1309.  
  1310.     RATIONALE:
  1311.     NewStringUTF constructs a Java string from a UTF string. Although 
  1312.     UTF strings are already 0-terminated, the function required an
  1313.     unnecessary length argument, forcing the programmer to write:
  1314.  
  1315.     NewStringUTF(env, s, strlen(s))
  1316.  
  1317.     instead of just:
  1318.  
  1319.     NewStringUTF(env, s) 
  1320.  
  1321. ____________________________
  1322. JAVA NATIVE INTERFACE CHANGE - Changed DeleteLocalRef and DeleteGlobalRef
  1323.  
  1324.     Now programmers can pass local or global references to DeleteLocalRef 
  1325.     and DeleteGlobalRef directly, instead of having to pass the address 
  1326.     of these references.
  1327.  
  1328.     RATIONALE:
  1329.     DeleteLocalRef and DeleteGlobalRef delete local or global references
  1330.     created by the JNI. They used to take the address of the reference,
  1331.     forcing programmers to write:
  1332.  
  1333.     DeleteLocalRef(&ref)
  1334.  
  1335.     now references are passed as follows:
  1336.  
  1337.     DeleteLocalRef(ref)
  1338.  
  1339. ____________________________
  1340. JAVA NATIVE INTERFACE CHANGE - Changed the "IsSubclassOf" function name
  1341.     to "IsAssignableFrom."
  1342.  
  1343.     RATIONALE:
  1344.     The following JNI (Java Native Interface) function was misnamed:
  1345.  
  1346.         jboolean IsSubclassOf(JNIEnv *env, jclass clazz1, 
  1347.                                            jclass clazz2);
  1348.  
  1349.     It did not match the Java Language Specification's definition 
  1350.     of the "subclass" relationship.
  1351.  
  1352.     The Reflection API has a similar method in java.lang.Class:
  1353.     
  1354.         boolean isAssignableFrom(Class class);
  1355.         
  1356.     This is a much more suitable name. The JNI function therefore changed 
  1357.     its name to:
  1358.     
  1359.         jboolean IsAssignableFrom(JNIEnv *env, jclass clazz1, 
  1360.                                                jclass clazz2);
  1361.  
  1362. ____________________________
  1363. JAVA NATIVE INTERFACE CHANGE - Change RegisterNatives so that it
  1364.     takes all the information in one array.
  1365.  
  1366.     RATIONALE:
  1367.     In beta3, the RegisterNatives function took three arrays
  1368.     containing native method names, signatures and function entry 
  1369.     pointers, respectively:
  1370.     
  1371.         jint RegisterNatives(JNIEnv env, jclass clazz, 
  1372.                const char *names[],
  1373.                const char *signatures[];
  1374.                void *nativeProcs[]);
  1375.          
  1376.     These arrays had to be of the same length, and had to be NULL-
  1377.     terminated. It's better to put all the info in a single array,
  1378.     and pass the length of the array as another argument:
  1379.     
  1380.         struct JNINativeMethod {
  1381.             char* name;
  1382.             char* signature;
  1383.             void* fnPtr;
  1384.         };
  1385.         typedef struct JNINativeMethod JNINativeMethod;
  1386.  
  1387.         void RegisterNatives(JNIEnv* env, jclass classID, 
  1388.                   const JNINativeMethod methods[], jsize count);
  1389.  
  1390.     Here's how code that uses this looks in FCS:
  1391.  
  1392.         JNINativeMethodSpec methods[] = {
  1393.             { "sin", "(D)D", &::sin },
  1394.             { "cos", "(D)D", &::cos },
  1395.             { "tan", "(D)D", &::tan }
  1396.         };
  1397.         env->RegisterNatives(env->FindClass("java/lang/Math"), methods, 3);
  1398.  
  1399.     Here's how the same code used to look in beta3:
  1400.  
  1401.         const char* names[] = { "sin", "cos", "tan", NULL };
  1402.         const char* signatures[] = { "(D)D", "(D)D", "(D)D", NULL };
  1403.         void* procs[] = { &::sin, &::cos, &::tan, NULL };
  1404.         env->RegisterNatives(env->FindClass("java/lang/Math"), 
  1405.                              names, signatures, proc);
  1406.     
  1407.     The former approach is clearer.
  1408.  
  1409. ____________________________
  1410. JAVA NATIVE INTERFACE CHANGE - Changed the typing scheme of references
  1411.     to Java objects.
  1412.  
  1413.     In JDK Beta 3, reference types are defined as follows:
  1414.  
  1415.     typedef void *jref;    /* generic type for references */
  1416.     typedef jref jobject;  /* Java objects */
  1417.     typedef jref jclass;   /* Java class objects */
  1418.     typedef jref jstring;  /* Java strings */
  1419.     typedef jref jarray;   /* Java arrays */
  1420.  
  1421.     The distinction between jref and jobject was not clear. In 1.1 FCS,
  1422.     we got rid of jref, and introduced additional reference types to more
  1423.     accurately convey the subtyping information. We introduced dummy C++
  1424.     classes to enforce the subtyping relationships:
  1425.  
  1426.     #ifdef __cplusplus
  1427.  
  1428.     class _jobject {};
  1429.     class _jclass : public _jobject {};
  1430.     class _jthrowable : public _jobject {};
  1431.     class _jstring : public _jobject {};
  1432.     class _jarray : public _jobject {};
  1433.     class _jbooleanArray : public _jarray {};
  1434.     class _jbyteArray : public _jarray {};
  1435.     class _jcharArray : public _jarray {};
  1436.     class _jshortArray : public _jarray {};
  1437.     class _jintArray : public _jarray {};
  1438.     class _jlongArray : public _jarray {};
  1439.     class _jfloatArray : public _jarray {};
  1440.     class _jdoubleArray : public _jarray {};
  1441.     class _jobjectArray : public _jarray {};
  1442.  
  1443.     typedef _jobject *jobject;
  1444.     typedef _jclass *jclass;
  1445.     typedef _jthrowable *jthrowable;
  1446.     typedef _jstring *jstring;
  1447.     typedef _jarray *jarray;
  1448.     typedef _jbooleanArray *jbooleanArray;
  1449.     typedef _jbyteArray *jbyteArray;
  1450.     typedef _jcharArray *jcharArray;
  1451.     typedef _jshortArray *jshortArray;
  1452.     typedef _jintArray *jintArray;
  1453.     typedef _jlongArray *jlongArray;
  1454.     typedef _jfloatArray *jfloatArray;
  1455.     typedef _jdoubleArray *jdoubleArray;
  1456.     typedef _jobjectArray *jobjectArray;
  1457.  
  1458.     #else
  1459.  
  1460.     struct _jobject;
  1461.  
  1462.     typedef struct _jobject *jobject;
  1463.     typedef jobject jclass;
  1464.     typedef jobject jthrowable;
  1465.     typedef jobject jstring;
  1466.     typedef jobject jarray;
  1467.     typedef jarray jbooleanArray;
  1468.     typedef jarray jbyteArray;
  1469.     typedef jarray jcharArray;
  1470.     typedef jarray jshortArray;
  1471.     typedef jarray jintArray;
  1472.     typedef jarray jlongArray;
  1473.     typedef jarray jfloatArray;
  1474.     typedef jarray jdoubleArray;
  1475.     typedef jarray jobjectArray;
  1476.  
  1477.     #endif
  1478.  
  1479.     JNI function types have been modified accordingly to accept or return
  1480.     the newly introduced reference types.
  1481.  
  1482. ____________________________
  1483. JAVA NATIVE INTERFACE CHANGE - Changed the typing of certain primitive
  1484.     types:
  1485.  
  1486.     The following types in earlier versions of JDK:
  1487.  
  1488.     typedef char jboolean;
  1489.     typedef char jbyte;
  1490.     typedef unsigned long jsize;
  1491.  
  1492.     have been changed to:
  1493.  
  1494.     typedef unsigned char jboolean;
  1495.     typedef signed char jbyte;
  1496.     typedef jint jsize;
  1497.  
  1498.     in JDK 1.1 FCS.
  1499.  
  1500.     Earlier, jsize was defined to be an unsigned integer type that has
  1501.     the same number of bits as a native pointer. The idea was to use
  1502.     jsize to represent array length and size, etc. However, there has
  1503.     been a great deal of confusion on what operations are available 
  1504.     on jsize, whether it is safe to convert jsize to int, etc. We
  1505.     changed jsize to be the same as jint because Java arrays and
  1506.     strings cannot be longer than 2^31 anyway. All standard Java
  1507.     methods that operate on arrays and strings use "int" as the
  1508.     length and size types.
  1509.  
  1510. ___________
  1511. TOOL CHANGE - New argument -s added to javap
  1512.  
  1513.     -s: Print method and field type signature information in the internal
  1514.         form used by the Java Virtual Machine.  This is the form through
  1515.         which a user of the Java Native Interface (JNI) refers to methods
  1516.         and fields. Using javap with the -s flag to print method and field
  1517.         information for a class to be accessed with the JNI avoids the 
  1518.         difficulty of constructing signatures in the obscure internal 
  1519.         format manually.
  1520.     
  1521.     Examples of use:
  1522.  
  1523.     % cat foo.java
  1524.     class foo {
  1525.         Thread thread;
  1526.         int i;
  1527.         public static void main(String args[]) {
  1528.         }
  1529.         private void foo() {}
  1530.     }
  1531.  
  1532.     % javap -p foo
  1533.     Compiled from foo.java
  1534.     class foo extends java.lang.Object 
  1535.         /* ACC_SUPER bit set */ 
  1536.     {
  1537.         java.lang.Thread thread;
  1538.         int i;
  1539.         public static void main(java.lang.String []);
  1540.         private void foo();
  1541.         foo();
  1542.     }
  1543.  
  1544.     % javap -p -s foo
  1545.     Compiled from foo.java
  1546.     class foo extends java.lang.Object 
  1547.         /* ACC_SUPER bit set */
  1548.     {
  1549.         thread Ljava/lang/Thread;
  1550.         i I
  1551.         public static main ([Ljava/lang/String;)V
  1552.         private foo ()V
  1553.         <init> ()V
  1554.     }
  1555.  
  1556. ___________
  1557. TOOL CHANGE - Added -deprecation flag to javac
  1558.  
  1559.     By default, when compiling a class that contains deprecated APIs, 
  1560.     javac now displays only a brief note, rather than immediately
  1561.     listing all of the deprecated APIs.  For example:
  1562.  
  1563.     % javac MyClass.java
  1564.     Note: MyClass.java uses deprecated APIs.  Recompile with "-deprecation" 
  1565.     for details.
  1566.  
  1567.     Then, you can re-compile using the -deprecation flag to get the
  1568.     name of the deprecated constructor, field, method, class or 
  1569.     interface.
  1570.  
  1571.     % javac -deprecation MyClass.java
  1572.     MyClass.java:3: Note: The constructor java.lang.String(byte[],int)
  1573.     has been deprecated.
  1574.         new String(new byte[0], 0);
  1575.         ^
  1576.     Note: wombat.java uses deprecated APIs.  Please consult the 
  1577.     documentation for a better alternative.
  1578.  
  1579.     At this point, please refer to the JDK API Reference documentation
  1580.     (the javadoc-generated web pages) jdk1.1/docs/api/packages.html.
  1581.     If you look up the deprecated API, it should give you more details
  1582.     such as which API replaces it.    
  1583.  
  1584.     To summarize the compiler options:
  1585.         javac -nowarn       => complete silence
  1586.         javac               => a one-line comment about deprecations
  1587.         javac -deprecation  => a full report
  1588.  
  1589.     RATIONALE:
  1590.     This can greatly reduce the amount of warning by default, allowing 
  1591.     developers to concentrate on the errors, and to have a graceful
  1592.     migration towards updating their deprecated code.
  1593.  
  1594.  
  1595. ===================================================================
  1596. Changes from JDK 1.1beta2 to JDK 1.1beta3
  1597. -------------------------------------------------------------------
  1598.  
  1599. The following changes and bug fixes are in the JDK 1.1beta3 release.
  1600.  
  1601. ______________
  1602. VERSION NUMBER - The version number for this release is "JDK1.1beta3.3". 
  1603.  
  1604.     Versions beta3.1 and beta3.2 were internal candidates that were 
  1605.     never released.
  1606.     You can get the version number of your particular release by executing:
  1607.  
  1608.         java -version
  1609.  
  1610. _______________
  1611. PACKAGE CHANGES - Two new packages in java.*: java.beans and java.math
  1612.     Changes in these packages are described in more detail below.
  1613.  
  1614. ________________
  1615. JAVABEANS CHANGE - JavaBeans1.0 is now part of JDK1.1
  1616.     The classes that define the JavaBeans 1.0 API specification
  1617.     are now part of JDK1.1.  These classes are part of BDK1.0
  1618.     beta1 and beta2; there will be a BDK1.0beta3 that synchronizes
  1619.     with JDK1.1beta3.
  1620.  
  1621.   - There has been one change in the JavaBeans APIs: the string
  1622.     argument to Beans.instantiate() has changed. The argument
  1623.     used to be the path to a serialized bean, it is now the
  1624.     name of a bean, which may be serialized, or just a class name.
  1625.  
  1626. ______________
  1627. GENERAL CHANGE - Extended the core API methods that take a PrintStream 
  1628.     argument so they can also take a PrintWriter argument.
  1629.  
  1630.     Several constructors and methods have been added to make the 
  1631.     new PrintWriter class easier to use.  
  1632.  
  1633. _________
  1634. IO CHANGE - Merged the functionality of the ByteToCharConverter 
  1635.     and CharToByteConverter classes into the InputStreamReader and
  1636.     OutputStreamWriter classes.
  1637.  
  1638.     The ByteToCharConverter and CharToByteConverter classes 
  1639.     are no longer public, so various constructors and methods
  1640.     that previously took converter arguments now accept names
  1641.     of character encodings.  The InputStreamReader and 
  1642.     OutputStreamWriter classes no longer commit to buffering
  1643.     the underlying byte stream.  Details on these and other
  1644.     changes may be found at:
  1645.  
  1646.     http://java.sun.com/products/JDK/1.1/docs/guide/io/b3-changes.html
  1647.  
  1648. ___________
  1649. LANG CHANGE - New method: identityHashCode in java.lang.System
  1650.  
  1651.     Its signature is:
  1652.  
  1653.     public static native int identityHashCode(Object x);
  1654.  
  1655.     It returns the same hashcode for the given object as
  1656.     would be returned by the default method hashCode(),
  1657.     whether or not the given object's class overrides hashCode().
  1658.     The hashcode for the null reference is zero.
  1659.  
  1660.     RATIONALE:  
  1661.     In previous releases, Java lacked a constant-time
  1662.     identity hash function.  This meant there was no way to build
  1663.     a hash table which keyed on object identity, and for which
  1664.     access would be a constant-time operation.
  1665.  
  1666.     Java supplied a constant-time identity comparison operation 
  1667.     (the built-in operator ==) but did not supply a corresponding
  1668.     constant-time identity hash operation.
  1669.  
  1670.     This new method is very useful when the object in question does
  1671.     override equals and hashCode, but the guts of some abstraction
  1672.     is working with canonicalized instances, such as interned 
  1673.     strings, and needs to use them as keys for fast lookups.
  1674.  
  1675.     Although this is sometimes done by wrapping the string-like
  1676.     object inside another object which does not override equals 
  1677.     and hashCode, it's desirable to allow such objects to be used
  1678.     directly as keys in identity tables, to avoid the overhead 
  1679.     of allocating the wrappers.
  1680.  
  1681.     When performance is not an issue, the method Object.hashCode() 
  1682.     suffices, even if it is slow (as with strings), but when
  1683.     performance must be maximized, neither the wrapper technique 
  1684.     nor the slow hashCode() method is workable, and only a fast
  1685.     identityHashCode() method will be suitable.
  1686.  
  1687. ___________
  1688. LANG CHANGE - getResourceAsName(String) changed to getResource(String)
  1689.  
  1690.     java.lang.Class and java.lang.ClassLoader used to have methods 
  1691.     with signature:
  1692.  
  1693.        String getResourceAsName(String)
  1694.  
  1695.     which would return an external representation to a URL to
  1696.     the desired resource file.  These methods have been replaced
  1697.     by methods with signature
  1698.  
  1699.        java.net.URL getResource(String)
  1700.  
  1701.     which return the actual URL (or null if the resource is not found).
  1702.  
  1703. ___________
  1704. AWT CHANGES - New type of event: ContainerEvent
  1705.  
  1706.   This change provides the hooks for containers to easily register event 
  1707.   listeners on descendents.
  1708.  
  1709.   - Added new ContainerEvent class and equivalent ContainerListener 
  1710.     interface to enable notification when components are added/removed
  1711.     from containers.  This makes it relatively easy for containers 
  1712.     to register themselves as listeners for events on all of their 
  1713.     descendents.
  1714.  
  1715.   - Added the addContainerListener/removeContainerListener methods
  1716.     to Container.
  1717.  
  1718.   RATIONALE:
  1719.   In beta2 the event model provided no reasonable mechanism
  1720.   to allow containers to get input events which occurred in their
  1721.   descendents, which turns out to be a fairly common need.
  1722.   The 1.0 event model allowed this by automatically propagating
  1723.   events up the containment hierarchy until some component returned
  1724.   "true" to absorb the event and stop the propagation.  While this
  1725.   seems powerful (and it's easy), the 1.0 propagation model is error
  1726.   prone and results in poor performance. 
  1727.      
  1728. ___________
  1729. AWT CHANGES - Further Fine-Tuning of AWT Input Event Related API
  1730.  
  1731.   Responding to customer feedback and testing, we made the following
  1732.   changes to the API in the java.awt and java.awt.event packages:
  1733.  
  1734.   - Added a TextEvent class and TextListener interface to enable
  1735.     programs to track all changes to a text component, including
  1736.     paste and programmatic modifications.  (Bug #4014945)
  1737.  
  1738.   - Added new windowActivated/windowDeactivated event types to WindowEvent 
  1739.     to enable programs to determine when a window gets/loses focus.
  1740.   
  1741.   - Added isTemporary method to FocusEvent to enable determining the
  1742.     difference between when focus is explicitly moved between components
  1743.     and when focus temporarily changes (such as when a window is
  1744.     de-activated).
  1745.   
  1746.   - Added a consume method to the InputEvent class, enabling any object
  1747.     to consume input events.  Previously, only the Component associated
  1748.     with the input event could consume it.
  1749.  
  1750.   - Made the AWTEventMulticaster class public, enabling component
  1751.     subclasses to serve as multicast sources for AWT-defined events.
  1752.   
  1753.   - Made the java.awt.event Adapter classes abstract so that it's clear
  1754.     that they need to be extended.
  1755.  
  1756.   - Removed constructors in java.awt.event Event classes that took
  1757.     an old 1.0 event as a parameter.
  1758.   
  1759.   - Changed the event id values of the ComponentEvent types to prevent them
  1760.     from clashing with the WindowEvent ids.
  1761.   
  1762.   - Added virtual keycode identifiers to KeyEvent to properly represent
  1763.     all standard keys on the keyboard.  The keyCode property of the key
  1764.     event now contains one of those identifiers (instead of the ASCII
  1765.     integer equivalent).
  1766.  
  1767.   - Added a method called isPopupTrigger to the MouseEvent class,
  1768.     providing a platform-independent way to determine whether a mouse
  1769.     event should result in a popup menu being shown. (Bug #4017794)
  1770.  
  1771. __________
  1772. AWT CHANGE - New method: getTreeLock() to java.awt.Component:
  1773.  
  1774.     The public field Component.LOCK will NOT be changed for beta3,
  1775.     to minimize the risk of the change for beta3, but it will be made
  1776.     non-public (package private) between beta3 and final release.
  1777.  
  1778.     RATIONALE:
  1779.     The AWT exposes a public static final field, called Component.LOCK, 
  1780.     for synchronizing operations that affect or depend on
  1781.     component-tree structure.  
  1782.  
  1783.     Exposing this field for public use unnecessarily constricts future
  1784.     AWT implementations to providing a single toolkit-wide lock.
  1785.  
  1786.     It is much better to provide access to the lock object by an
  1787.     instance method on class Component, such that future
  1788.     implementations can return a context-sensitive locking object if
  1789.     they need to.
  1790.  
  1791. __________
  1792. AWT CHANGE - New Component method: getLocationOnScreen
  1793.  
  1794.     Added one new method to the Component class:
  1795.  
  1796.       Point getLocationOnScreen()
  1797.  
  1798.     RATIONALE:
  1799.     This method returns the current location of the component in
  1800.     the screen's coordinate space.
  1801.  
  1802. __________
  1803. AWT CHANGE - New Choice method: insert
  1804.  
  1805.     Added one new method to the Choice class:
  1806.  
  1807.       void insert(String item, int index) 
  1808.  
  1809.     RATIONALE:
  1810.     This method lets you insert items into a Choice control at the index
  1811.     you specify.  (In Beta2, items were always added at the end.)
  1812.  
  1813. __________
  1814. AWT CHANGE - ItemSelectable interface change 
  1815.  
  1816.     Removed the following two methods from the ItemSelectable interface:
  1817.        public int[] getSelectedIndexes();
  1818.        public String[] getSelectedItems();
  1819.  
  1820.     They have been replaced by the following method:
  1821.        public Object[] getSelectedObjects();
  1822.  
  1823.     RATIONALE:
  1824.     This change removes the restriction that an item must be representable
  1825.     by a String.  The AWT classes that implement ItemSelectable (List,
  1826.     Choice, Checkbox, and CheckboxMenuItem) have changed accordingly.
  1827.  
  1828. __________
  1829. AWT CHANGE - Allow Container and Component classes to be extended 
  1830.     directly to create lightweight components.
  1831.  
  1832.   1) Added the following method to java.awt.Component
  1833.  
  1834.     Dimension getMaximumSize();
  1835.  
  1836.      In beta2 components could specify only their minimum and preferred
  1837.      sizes and assume that the component was infinitely stretchable.  
  1838.      This assumption is invalid with lightweight components where components
  1839.      tend to be written at a finer granularity and some components don't
  1840.      want to be flexible.
  1841.  
  1842.      The default implementation of this method specifies infinite
  1843.      size to reflect the current behavior.
  1844.  
  1845.   2) Added two alignment functions to java.awt.Component.
  1846.  
  1847.         float getAlignmentX();
  1848.     float getAlignmentY();
  1849.  
  1850.      that return a number between 0.0 and 1.0.  These values specify how 
  1851.      to align the component relative to other components.  0.0 would be
  1852.      aligned at the origin, 1.0 the furthest away from the origin, 
  1853.      0.5 is centered, etc.  As examples, a text component would have a
  1854.      y alignment to the baseline, and an icon component would have 
  1855.      an alignment to its hotspot, if defined.
  1856.  
  1857.     RATIONALE:
  1858.     Before beta3 the only way of creating new components in the AWT was
  1859.     to extend Canvas, Panel, and their subclasses.  Component and
  1860.     Container could not be directly extended.  All components were
  1861.     automatically "heavyweight" in that each had an opaque native
  1862.     window associated with them.  The problem with this is that heavyweight
  1863.     components are expensive (you can't afford to have too many) and
  1864.     they cannot have any transparent pixels.  The new changes create
  1865.     standard support for lightweight components.
  1866.  
  1867. ____________
  1868. MATH CHANGES - New package: java.math, which initially contains two 
  1869.     classes:  BigInteger and BigDecimal.
  1870.  
  1871.     BigNum class has been removed and replaced by BigInteger and BigDecimal.
  1872.  
  1873.     BigIntegers are immutable arbitrary-precision integers, which provide
  1874.     analogs to all of Java's primitive integer operators, and all relevant
  1875.     static methods from java.lang.Math.  Additionally, BigIntegers provide
  1876.     operations for modular arithmetic, GCD calculation, primality testing, 
  1877.     prime generation, single-bit manipulation, and a few other odds and ends.
  1878.  
  1879.     BigDecimals are immutable, arbitrary-precision signed decimal numbers,
  1880.     suitable for monetary calculations.  BigDecimals provide operations for 
  1881.     basic arithmetic, scale manipulation, comparison, format conversion 
  1882.     and hashing.  The BigDecimal class gives its user complete control 
  1883.     over rounding behavior, forcing the user to explicitly specify a 
  1884.     rounding behavior for operations capable of discarding precision.
  1885.  
  1886. ________________
  1887. SECURITY CHANGES -  New method: getProviders(), which provides 
  1888.     a way to query which crypto providers are installed.
  1889.  
  1890.     This method is added to the Security class and has the form:
  1891.  
  1892.     public static String[] getProviders();
  1893.  
  1894. ___________
  1895. TOOL CHANGE - javakey is now able to export keys and certs
  1896.     to files.
  1897.  
  1898.     This is a change to the javakey tool, a reciprocal to
  1899.     the existing import facility.
  1900.  
  1901. ___________
  1902. TOOL CHANGE - javac -nowarn flag now suppresses @deprecated messages  
  1903.  
  1904.     This can greatly reduce the amount of messages, allowing you
  1905.     to see only the errors.
  1906.  
  1907. ____________
  1908. TOOL CHANGES - jar tool is incompatible with earlier JAR files
  1909.  
  1910.     The beta3 jar tool (more specifically, ZipInputStream and
  1911.     ZipOutputStream) is incompatible with JAR files created with
  1912.     the beta2 jar tool.  The JAR tool won't understand those files.
  1913.     There was a bug in beta2 ZipInputStream and ZipOutputStream 
  1914.     such that those classes didn't generate files properly according
  1915.     to the zip specification (one bit out of place means a lot...)
  1916.     The bug was fixed and now it generates proper zip files that 
  1917.     other tools will understand.
  1918.  
  1919. ____________
  1920. TOOL CHANGES - Removed ability to generate MIF from javadoc
  1921.  
  1922.     Removed "-doctype MIF" option from javadoc.  This was necessary
  1923.     in order to remove the HTML parser dependency that HotJava had
  1924.     on the JDK.
  1925.  
  1926. ===================================================================
  1927. Changes from the original JDK 1.1beta to JDK 1.1beta2
  1928. -------------------------------------------------------------------
  1929.  
  1930. The following fixes and improvements are in the JDK 1.1beta2 release.
  1931.  
  1932. ______________
  1933. VERSION NUMBER - The version number for this release is "JDK1.1beta2". 
  1934.  
  1935.     You can get the version number of your particular release by executing:
  1936.  
  1937.         java -version
  1938.  
  1939. _______
  1940. CHANGE - Source code for public classes included
  1941.  
  1942.     The source code for the public classes in the java.* package are 
  1943.     now included in this release in the file src.zip.  These correspond
  1944.     to the public classes contained in classes.zip.  This src.zip
  1945.     is equivalent to that shipped previously with JDK 1.0.2
  1946.     but also includes sources to the new public classes added in JDK 1.1. 
  1947.  
  1948. _______
  1949. BUG FIX - Jar tool manifest-build limitation on number of files on Solaris
  1950.  
  1951.     DESCRIPTION OF BUG
  1952.     In some configurations of Solaris, trying to create a JAR file 
  1953.     that has more than 64 entries in it would fail.  The command 
  1954.     that would cause this to happen is:
  1955.  
  1956.     % jar cvf test.jar <somedir>
  1957.   
  1958.     where <somedir> is a directory containing more than 64 files.
  1959.  
  1960.     SOLUTION - This bug has been fixed.
  1961.  
  1962. _______
  1963. BUG FIX - Javakey tool signs jar files with invalid signatures
  1964.  
  1965.     DESCRIPTION OF BUG
  1966.     An implementation inconsistency in the javakey security tool causes
  1967.     jar files to be signed with invalid signatures. This means that 
  1968.     signature checking will always fail, thus all applets will run as 
  1969.     untrusted, with minimal permissions enabled.  This makes code signing
  1970.     feature unusable but it is not a security hole.  
  1971.  
  1972.     SOLUTION - This bug has been fixed. 
  1973.  
  1974. _______
  1975. BUG FIX - 4017054 - Limit to numeric range of case statements
  1976.  
  1977.     DESCRIPTION OF BUG
  1978.     If a Java switch statement includes case statements that cover a wide
  1979.     range of numerical values (although not necessarily a large number of 
  1980.     cases themselves), the Java compiler can run out of memory attempting 
  1981.     to compile that statement.  For instance, a switch statement 
  1982.     containing the two cases 0 and 99999999 will cause the compiler to 
  1983.     run out of memory.
  1984.  
  1985.     SOLUTION - This bug has been fixed.
  1986.  
  1987. _______
  1988. BUG FIX - 4018832 - Missing class java.io.LineNumberReader
  1989.  
  1990.     DESCRIPTION OF BUG
  1991.     In the Win32 release, the class java.io.LineNumberReader is
  1992.     documented but the class file is absent from classes.zip
  1993.  
  1994.     SOLUTION - java.io.LineNumberReader has been added to classes.zip
  1995.  
  1996. _______
  1997. BUG FIX - 4018252 - DecimalNumberFormat methods throw exceptions
  1998.  
  1999.     DESCRIPTION OF BUG
  2000.     The class java.text.DecimalNumberFormat throws an exception when any 
  2001.     of its format or parse methods are called.  A typical stack trace 
  2002.     looks something like the following:
  2003.  
  2004.     java.lang.NumberFormatException: 451.0D
  2005.         at java.lang.Double.<init>(Double.java)
  2006.         at java.text.DigitList.getRealDouble(DigitList.java)
  2007.         at java.text.DigitList.set(DigitList.java)
  2008.         at java.text.DecimalFormat.format(DecimalFormat.java)
  2009.         at java.text.NumberFormat.format(NumberFormat.java)
  2010.  
  2011.     Although DecimalNumberFormats are generally not used directly, they 
  2012.     are returned by calls to NumberFormat.getDefault(), 
  2013.     NumberFormat.getDefaultCurrency() and NumberFormat.getDefaultPercent().
  2014.  
  2015.     SOLUTION - This bug has been fixed.
  2016.  
  2017.