Java Community Process^SM Maintenance Review
for J2SE^TM 1.4 Beta 3

Introduction

This site provides details of specification changes being made in version 1.4 ("Merlin") of the Java^TM 2 Platform, Standard Edition (J2SE^TM). The descriptions on this site correspond to the platform changes that were made since the Beta 2 release of J2SE 1.4 and which are present in the Beta 3 release of J2SE 1.4. Descriptions of any post-Beta 3 specification changes will be provided in the future for separate review.

Merlin contains a variety of new features, of varying scale. Major features have been addressed by separate component JSRs (there are thirteen component JSRs in Merlin), but smaller features (such as, for example, new GUI widgets) are being addressed under the JCP maintenance rules.

The major new features of the Merlin release are described in JSR-059 "Merlin Release Contents". However, as that document states:

"This specification will not itself define any new APIs, rather it will reference APIs defined in other JCP Specifications or through the JCP maintenance process."

So, as with the component JSRs, the individual non-JSR API changes are being reviewed separately in the JCP process, in this case through a JCP maintenance review. Similarly to the review process for the Merlin component JSRs, any feature that fails its maintenance review will be dropped from Merlin and removed from the JSR-059 feature list.

Feedback

Please use the following address to provide review feedback on the platform changes described here.

merlin-jsr@eng.sun.com

Change Descriptions

Changes and enhancements to the Java 2 Platform since J2SE 1.4 Beta 2 that are included in J2SE 1.4 Beta 3 are summarized by functional area at the links below. The description of each change includes links to the affected parts of the API specification as well as to any bug reports that are relevant to the change.

AWT/Java 2D^TM Technology
Endorsed Standards Override Mechanism
CORBA
Reflection
Security
Swing
Java Native Interface
Regular Expressions
Internationalization
Networking
Javadoc Tool

Also available are difference files that highlight all changes in the Javadoc API specifications between J2SE 1.4 Beta 2 and J2SE 1.4 Beta 3. See

Specification Difference Files

The following applies to two new methods introduced in 1.4:

• SystemFlavorMap.addUnencodedNativeForFlavor()
• SystemFlavorMap.addFlavorForUnencodedNative()

This API change updates the above specifications to state that these methods have no effect if the mapping already exists. The implementation has also been updated accordingly.

Additionally, related methods of SystemFlavorMap previously had their behavior undocumented for the following special cases:

• setNativesForFlavor() and setFlavorsForNative() throw NullPointerException if the passed array contains null elements, but this was not documented
• setNativesForFlavor() and addUnencodedNativeForFlavor() affect not only the specified DataFlavor, but all equal DataFlavors as well. This was not documented and could confuse test developers, since equal DataFlavors can seem different. For example, the two objects DataFlavor("text/plain; class=java.io.InputStream") and DataFlavor("text/plain") were equal according to the previous specification. Consequently, any call to setNativesForFlavor() or addUnencodedNativeForFlavor() for either of the two flavors will affect mappings for both of them.

This API change specifies the behavior in these cases. It consists of the following:

1. Updated the specification for java.awt.datatransfer.SystemFlavorMap.addUnencodedNativeForFlavor(DataFlavor flav, String nat)
2. Updated the specification for java.awt.datatransfer.SystemFlavorMap.addFlavorForUnencodedNative(String nat, DataFlavor flav)
3. Updated the specification for java.awt.datatransfer.SystemFlavorMap.setNativesForFlavor(DataFlavor flav, String[] natives)
4. Updated the specification for java.awt.datatransfer.SystemFlavorMap.setFlavorsForNative(String nat, DataFlavor[] flavors)

The bug report associated with this change is 4493189.

This change tightens the semantics for all Rasters to explicitly throw RasterFormatException when width or height are negative or zero and when computing a supposedly valid x or y coordinate in the Raster would cause integer overflow. The change is implemented by changing/adding a small number of lines of code, but includes javadoc changes to a large number of methods and constructors that indirectly execute the changed code.

Code changes:

java.awt.image.Raster

• protected Raster(SampleModel sampleModel, DataBuffer dataBuffer, Rectangle aRegion, Point sampleModelTranslate, Raster parent) now throws a RasterFormatException
• public Raster createChild(int parentX, int parentY, int width, int height, int childMinX, int childMinY, int bandList[]) now throws a RasterFormatException

java.awt.image.WritableRaster

• public WritableRaster createWritableChild(int parentX, int parentY, int w, int h, int childMinX, int childMinY, int bandList[]) method now throws a RasterFormatException

Equivalent javadoc changes (no code changes) have been made to the following constructors/methods which call the above constructors/ methods:

Raster.java constructors

• protected Raster(SampleModel sampleModel, Point origin)
• protected Raster(SampleModel sampleModel, DataBuffer dataBuffer, Point origin)

Raster.java methods

• public static WritableRaster createInterleavedRaster(int dataType, int w, int h, int bands, Point location)
• public static WritableRaster createInterleavedRaster(int dataType, int w, int h, int scanlineStride, int pixelStride, int bandOffsets[], Point location)
• public static WritableRaster createBandedRaster(int dataType, int w, int h, int bands, Point location)
• public static WritableRaster createBandedRaster(int dataType, int w, int h, int scanlineStride, int bankIndices[], int bandOffsets[], Point location)
• public static WritableRaster createPackedRaster(int dataType, int w, int h, int bandMasks[], Point location)
• public static WritableRaster createPackedRaster(int dataType, int w, int h, int bands, int bitsPerBand, Point location)
• public static WritableRaster createInterleavedRaster(DataBuffer dataBuffer, int w, int h, int scanlineStride, int pixelStride, int bandOffsets[], Point location)
• public static WritableRaster createBandedRaster(DataBuffer dataBuffer, int w, int h, int scanlineStride, int bankIndices[], int bandOffsets[], Point location)
• public static WritableRaster createPackedRaster(DataBuffer dataBuffer, int w, int h, int scanlineStride, int bandMasks[], Point location)
• public static WritableRaster createPackedRaster(DataBuffer dataBuffer, int w, int h, int bitsPerPixel, Point location)
• public static Raster createRaster(SampleModel sm, DataBuffer db, Point location)
• public static WritableRaster createWritableRaster(SampleModel sm, Point location)
• public static WritableRaster createWritableRaster(SampleModel sm, DataBuffer db, Point location)
• public WritableRaster createCompatibleWritableRaster(Rectangle rect)
• public WritableRaster createCompatibleWritableRaster(int x, int y, int w, int h)
• public Raster createTranslatedChild(int childMinX, int childMinY)

WritableRaster.java constructors

• protected WritableRaster(SampleModel sampleModel, Point origin)
• protected WritableRaster(SampleModel sampleModel, DataBuffer dataBuffer, Point origin)
• protected WritableRaster(SampleModel sampleModel, DataBuffer dataBuffer, Rectangle aRegion, Point sampleModelTranslate, WritableRaster parent)

WritableRaster.java methods

• public WritableRaster createWritableTranslatedChild(int childMinX, int childMinY)

The bug report that corresponds with this change is 4491919.

This addition introduces the ability to support full-screen exclusive mode and its relevant issues, such as display mode control and complex video buffering.

API Change:

I. Enabling Full Screen

• Three new public methods added to java.awt.GraphicsDevice (isFullScreenSupported, get/ setFullScreenWindow)

II. Display Mode Control

• One new public final class in java.awt (DisplayMode)
• Four new public methods added to java.awt.GraphicsDevice (isDisplayChangeSupported, get/ setDisplayMode, getDisplayModes)

III. Video Buffer Control

• One new public classes in java.awt.image (BufferStrategy)
• Three new public methods added to java.awt.Canvas
  • public BufferStrategy getBufferStrategy()
  • public void createBufferStrategy(int numBuffers)
  • public void createBufferStrategy(int numBuffers, BufferCapabilities caps) throws AWTException

  and java.awt.Window

  • public BufferStrategy getBufferStrategy()
  • public void createBufferStrategy(int numBuffers)
  • public void createBufferStrategy(int numBuffers, BufferCapabilities caps) throws AWTException

• Two new protected inner classes in java.awt.Component (FlipBufferStrategy, BltBufferStrategy)
• Two new public methods added to java.awt.Component (get /setIgnoreRepaint)

IV. Capabilities and VolatileImage

• Two new public classes in java.awt (BufferCapabilities, ImageCapabilities)
• Four new public methods added to java.awt.GraphicsConfiguration (getBufferCapabilities, getImageCa pabilities, createCompatibleVolatileImage(int width, int height), createCompatibleVolatileImage(int width, int height, ImageCapabilities caps)
• One new public method in VolatileImage (getCapabilities)

The bug report that corresponds with this change is 4189326.

Endorsed Standards Override Mechanism

The Java 2 Platform includes a number of APIs that are governed by third-party endorsed standards. Examples are of such APIs are javax.rmi.CORBA.*, org.omg.*, and org.w3c.dom. Often software developers and vendors would like to use their own implementation of these APIs, or use a version of the external standard other than the version that is implemented in J2SE. To address this need, J2SE 1.4 supports the Endorsed Standards Override Mechansim, which makes use of new system property, java.endorsed.dirs.

The bug report associated with this addition is 4394071.

CORBA

To comply with the CORBA 2.3.1 specification, this API change updates the following methods of org.omg.CORBA.Any

from:

• abstract public void insert_Object( org.omg.CORBA.Object obj ) throws BAD_PARAM
• abstract public void insert_Object( org.omg.CORBA.Object obj, org.omg.CORBA.TypeCode t ) throws org.omg.CORBA.BAD_OPERATION

to:

• abstract public void insert_Object( org.omg.CORBA.Object obj )
• abstract public void insert_Object( org.omg.CORBA.Object obj, org.omg.CORBA.TypeCode t ) throws org.omg.CORBA.BAD_PARAM

The bug report that corresponds with this change is 4504690.

Reflection

The previous implementation of reflect.Modifier.toString was underspecified, contained inconvenient choices, and contained a bug with respect to the the implied specification.

This API change addresses these problems as follows:

• properly documents the total modifier order being used in Modifer.toString
• fixes code to output modifiers in that order
• clarifies origin of bit patterns for constants

See the updated specifications for java.lang.reflect.Modifier

• class summary
• toString()

The bug report that corresponds to this change is 4394937.

Security

• javax.security.cert exists for backwards compatibility with JSSE 1.0.x only, any future development should use the java.security.cert package instead.

  Our original approach was to provide equivalent API's to obtain both java.security.cert and javax.security.cert certificates, but have since decided that we should be discouraging further use of the javax.security.certs.

  This change removes the HttpsURLConnection method that returns the javax.security.cert certificates. There are no compatibility issues because this class did not exist in previous versions of J2SE or JSSE.
  

  This API change removes the following method from javax.net.ssl.HttpsURLConnection:

  • public abstract javax.security.cert.X509Certificate [] getServerCertificateChain() throws SSLPeerUnverifiedException

  The bug report associated with this change is 4502092.

• PKCS API specified in JSR074 includes support for PKCS 1, 5, and 8. JCA/JCE does provide support for PKCS 1, PKCS 5 and PKCS 8. But as the PKCS standards evolve, existing JCA/JCE APIs are not sufficient for the current PKCS standards. Thus, JCA/JCE have been enhanced to support these new features. The following is a list of features required for supporting current PKCS 1, 5, and 8 standards in JCA/JCE:
  • PKCS1: Support for Multi-Prime RSA Private Key and KeySpec
  • PKCS1: Parameter Support for EMSA-PSS
  • PKCS5: Support for Key used by PBES2 and PBMAC1
  • PKCS8: Support for EncryptedPrivateKeyInfo

  This API change consists of the following:

  1. Added class java.security.spec.RSAOtherPrimeInfo to represent the RSA ASN.1 structure "OtherPrimeInfo" which are used in multi-prime RSA private key in CRT form.
  2. Added class java.security.spec.RSAMultiPrimePrivateCrtKeySpec to enable setting and retrieving the triplet(s) to the CRT representation of RSA private key specs.
  3. Added interface java.security.interfaces.RSAMultiPrimePrivateCrtKey to enable retrieving the triplet(s) from the CRT representation of RSA private key.
  4. Added class java.security.spec.PSSParameterSpec so users can pass the desired salt length to Signature engine as parameters.
  5. Enhanced existing class javax.crypto.spec.PBEKeySpec to accept salt, iterationCount, and preferred key length (optional) in addition to password.
  6. Added interface javax.crypto.interfaces.PBEKey to provide a way to retrieve the necessary information for converting itself to PBEKeySpec.
  7. Added class javax.crypto.EncryptedPrivateKeyInfo to support ASN.1 structure EncryptedPrivateKeyInfo as defined in PKCS 8.

  The bug report associated with this change is 4478091.

• The Java Secure Socket Extension (JSSE) enables secure Internet communications. It implements a Java version of SSL (Secure Sockets Layer) and TLS (Transport Layer Security) protocols and includes functionality for data encryption, server authentication, message integrity, and client authentication. SSL and TLS are public-key-based network security protocols widely used to authenticate, privacy-protect, and ensure message integrity of transactions made over the Internet.

  TrustManagerFactory and KeyManagerFactory are the engine classes that are implemented in terms of Service Provider Interface.

  According to the Java Cryptography Specification (JCA), all API methods of an engine class should be declared "final". However, certain methods in TrustManagerFactory and KeyManagerFactory engine classes were not previously declared "final". These include:

  • Methods that intialize the factories with key and trust material.
  • Methods that access key and trust managers provided by the factory for each type of key material.

  This API change declares the following methods as "final".

  javax.net.ssl.TrustManagerFactory:

  • public final void init(KeyStore ks) throws KeyStoreException
  • public final void init(ManagerFactoryParameters spec) throws InvalidAlgorithmParameterException
  • public final TrustManager[] getTrustManagers()

  javax.net.ssl.KeyManagerFactory:

  • public final void init(KeyStore ks, char[] password) throws KeyStoreException, NoSuchAlgorithmException, UnrecoverableKeyException
  • public final void init(ManagerFactoryParameters spec) throws InvalidAlgorithmParameterException
  • public final KeyManager[] getKeyManagers()

  The bug report associated with this change is 4491400.

• The extended key usage field is used in X509v3 certificate to indicate one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension field. RFC 2459: "Internet X. 509 Public Key Infrastructure Certificate and CRL Profile" specifies that if extended key usage field is flagged as critical, applications must check to make sure the certificate is only used for a purpose consistent with its setting.

  In order to fix 4427888, we need to access this field.

  Previously there was no public API in java.security.X509Certificate to obtain information from the extended key usage field. This change adds a new public method to return such information. We also change the exception thrown by two new methods introduced in 1.4 to be consistent with the newly proprosed getExtendedKeyUsage method signature.

  API changes:

  Added the following method in java.security.cert.X509Certificate:

  • public List getExtendedKeyUsage() throws CertificateParsingException

  We also change the exception thrown by two new methods introduced in 1.4 to be consistent with the newly added getExtendedKeyUsage method signature.

  • public Collection getSubjectAlternativeNames() throws CertificateParsingException
  • public Collection getIssuerAlternativeNames() throws CertificateParsingException

  The checks performed by javax.net.ssl.X509TrustManager.isClientTrusted() and isServerTrusted() include verifying that the certificate is used for an operation that complies with the certificate's key usage extension. To properly perform this check it is necessary to pass the authentication type to these methods. The previous method signatures in javax.net.ssl.X509TrustManager class could not accommodate passing the authentication type in order for the key usage field to be checke correctly. Thus these two method signatures (which were introduced in 1.4) are now changed.

  This change modifies the following two methods to take an extra parameter:

  • public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException
  • public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException

  The bug report associated with this change is 4427888.

• The SecureRandom class previously did not specify the quality of the entropy that the underlying provider must supply; only the vague reference to "cryptographically strong" existed. This was probematic for source licensees since they had no benchmark by which to compare for their providers.

  Additionally, SecureRandomSpi implementations are free to interpret "cryptographically strong" to meet thier particular needs.

  Finally users of the API have no assurance to the quality of the RNG.

  This API change strictly tightens the specification of java.security.SecureRandom.

  The bug report associated with this change is 4492865.

Swing

• A recent bug fix to the Swing side of the focus rearchitecting in 1.4, 4482235, resulted in the javadoc for javax.swing.LayoutFocusTraversalPolicy.accept becoming incomplete. This API change enhances that javadoc to specify additional criteria.

  Changed javadoc for LayoutFocusTraversalPolicy.accept

  • protected boolean accept(Component aComponent)

  The bug report associated with this change is 4492285.

• In the process of enabling JTable to handle right-to-left component orientations, it was necessary to clarify the specifiation for the method getColumnIndexAtX in the interface javax.swing.table.TableColumnModel and the corresponding implementation of this method in javax.swing.table.DefaultTableColumnModel. Because of Swing's separable model architecture, the table model is not able to account for differing orientations. The specifiction has been clarified to make that fact explicit and points developers to a similar method in JTable which is able to account for orientation changes.

  This same change has been made in DefaultTableColumnModel.

  This change was made to address bug 4250708.

• Prior to Beta3, SpringLayout installed a Spring that constrained the x location of the Component to the value returned from getX and the y location was constrained to the value returned from getY. In other words, by default SpringLayout behaved similarly to a null layout where the developer directly set the x/y location on the Component to determine where the Component should be layed out. This was a problem in that LayoutManagers that respected the ComponentOrientation typically needed to flip the x position based on the width of the parent. This has been fixed as of Beta3.

  The bug report associated with this change is 4504132.

New Invocation Interface routine AttachCurrentThreadAsDaemon allows native code to attach a daemon thread to the Java virtual machine (VM); this is useful when the VM should not wait for this thread to exit upon shutdown. For more information on this new routine, see JNI Enhancements.

This change was made as part of bug 4496330.

One of the last remaining differences between Perl's syntax for regular expressions and that of the Java 2 Platform's support for regular expressions was that the Java syntax uses {xxx} POSIX character classes and Unicode blocks and categories. The Java 2 Platform has now adopted the Perl syntax, \p{xxx} and \P{xxx}, and supports all the POSIX categories and language blocks that Perl does.

The bug report that corresponds to this change is 4495089.

The following changes pertain to internationalization functionality in J2SE 1.4 Beta 3.

• J2SE 1.4 Beta included a feature for setting the default value of a JComponent's componentOrientation property based on the setting of that component's locale Property. This feature was intended to make most programs have the correct orientation without the programmers having to write any code.

  It turns out, however, that in many cases applications written in a "left-to-right" language such as English are run in right-to-left locales even though the application itself has not been translated to the right-to-left language. Such applications would have a mismatch between text orientation and the orientation of the GUI, making them difficult to use. Because of this problem, this feature has been removed in J2SE 1.4 Beta 3. Specifically, the following changes have been made:

  • The setLocale methods have been removed from JComponent, JFrame, JDialog, JApplet, and JWindow.

  • The following text has been added to the specifications for each of the contructors of JComponent, JFrame, JDialog, JApplet, and JWindow:

    This constructor sets the component's locale property to the value returned by JComponent.getDefaultLocale.

    This change was made to address 4505945.

• A new method, createInputMethodJFrame, has been added to the java.awt.im.spi.InputMethodContext interface to provide Java input methods with Swing based input method windows. Adding a new method to an existing interface usually breaks the upward binary compatibility, but as the java.awt.im.spi.InputMethodContext interface is implemented only by the JRE, there is no compatibility problem for existing Java applications. When writing new Java input methods based on the J2SDK  1.4.0, input method implementors are encouraged to use the reflection mechanism to call this method since it is not available in prior releases.

  This change was made to address 4453609.

• In request 4257115, new encode and decode methods were added to java.net.URLEncoder and URLDecoder. In addition, the behavior of the existing encode and decode methods was changed in order to be compatible with W3C recommendations (that UTF-8 should be used as the character encoding) for unsafe characters in URLs. Previously, the platforms default encoding was used, which is not compatible with the standards and possibly more seriously, could result in inconsistent results depending on the locale where the application is running.
  
  This change is however an incompatibility, and has resulted in breaking applications that run correctly on 1.3. It affects applications that run typically on Windows in US or Western European locales, and in which URLs are used that contain non-English characters (eg. word "resume", with an accent on the last "e") In 1.3, the default character set was used which encodes the accented "e" character as a single byte. In 1.4, UTF-8 is used which encodes the "e" as two bytes. In encoded URLs it is not always possible to determine which character set was used to encode it (eg. in HTTP headers such as the request URI field), so this situation results in applications breaking.
  
  This change restores the behavior of URLEncoder.encode(String) and URLDecoder.decode(String) to that which applied in 1.3. We also deprecate these methods because of the subtle dependency on the platforms default encoding (which was the reason for changing it in the first place). This dependency can cause applications to break when run in incompatible locales. Taking the example of the French word "resume" again, this will not encode correctly in any Asian locale, or in the 7-bit ASCII "C" locale) because the accented "e" does not exist in those character sets. Developers will be encouraged to use the new methods where the character set is explicitly defined. But applications that were working in 1.3 using the old methods
  will continue to work in 1.4.
  
  This API change involves the following:

  • Update class specification for URLEncoder
  • Update method specification for URLEncoder.encode(String)
  • Update class specification for URLDecoder
  • Update method specification for URLDecoder.decode(String)

  The bug report associated with this change is 4498214

• This change addresses issues raised in the following bug reports:
  
  4438319: URI should be explicit about escaped encoding
  4468322: Need APIs to support URI representing a platform path name
  4503239: URI.resolve works incorrectly when reference is just a fragment
  4505046: URI inconsistently specifies/handles brackets around IPv6 addrs
  

  4438319: The java.net.URI class is not explicit about whether or not characters that are not legal URI characters are escaped with the %XX convention and, if they are, what charset is used to encode them.

  4468322: The java.io.File class does not provide a way to create a properly-encoded URL or URI from a File object. This is necessary in order to support file names with unusual characters (e.g., "#" in Solaris cd-rom pathnames) when they appear in URL class paths and in other contexts. File names of this sort have long been a problematic source of bugs whose solutions have been very difficult due to compatibility constraints (4359123, 4416056, 4420304, 4420891, 4426271, 4428253, 4429806, 4429813).
  
  4503239: When resolving a lone fragment "#s" against a base URI that has a query component (e.g., "http://a/b/c/d;p?q"), the URI class drops the query component. This is inconsistent with RFC 2396.
  
  4505046: The fix to 4451522 (URI and URL getHost() methods don't comform to RFC 2732) changed the specification to say that brackets around IPv6 addresses are optional in the argument to the URI(String) constructor. In fact they're required for that constructor, but optional for the constructors that take standalone hostnames.
  
  4438319: URI should be explicit about escaped encoding
  
  This API change involves the following:

  • Revised the specification of the URI class to explain the handling of escaped octets, quotation, encoding, and decoding.
  • Revised the specification of the single-argument URI constructor to say that any illegal characters must be quoted.
  • Revised the specifications of the multi-argument URI constructors to say that any illegal characters in the user-information, path, query, and fragment components will automatically be encoded by these constructors.
  • Revised the specifications of the getUserInfo, getPath, getQuery, getFragment, getAuthority, and getSchemeSpecificPart methods to say that they always decode any escaped octets in their corresponding components.
  • Add the getRawUserInfo, getRawPath, getRawQuery, getRawFragment, getRawAuthority, and getRawSchemeSpecificPart methods to provide access to the corresponding components without interpretation of escaped octets.
  • Added the URI.toASCIIString() method, which evaluates all escaped octets in a URI instance and returns a string with characters only in the US-ASCII charset.
  • Added the File.toURI() method, which works much like the existing toURL() method except that it returns a properly-escaped file: URI.
  • Added the File(URI) constructor, which maps a file: URI back into an equivalent File object.
  • Revised the specification of the URI.resolve(URI) method to be consistent with RFC 2396.
  • Revised the specification of the URI(String) constructor to say that brackets around an IPv6 address are required.
  • Revised the specification of the seven-argument URI constructor to say that if the host is given, is an IPv6 address, and is not enclosed in square brackets then the square brackets will be added.
  • Revised the specification of the five-argument URI constructor to say that if the authority component is given and contains an IPv6 address then the address must be enclosed in square brackets.
  
  
• Many methods in java.net.URL were never specified to distinguish between null and empty Strings. This API change makes this clarification by updating the specification for the following methods:
  • public String getQuery
  • public String getUserInfo
  • public String getRef
  • public String getPath
  • public String getFile

  This bug report that corresponds to this change is 4487495.

• The following methods have been added to class java.net.InetSocketAddress.

  public final boolean equals(Object obj)
  public final int hashCode()
  

  This change was made to address 4503568.

• The following methods have been added to the networking API to provide means for returning a SocketAddress.

  Socket.getRemoteSocketAddress
  Socket.getLocalSocketAddress
  ServerSocket.getLocalSocketAddress
  DatagramSocket.getRemoteSocketAddress
  DatagramSocket.getLocalSocketAddress
  

  This change was made to address request for enhancement 4503651.

• The java.net.NetworkInterface class was introduced in J2SE 1.4.0 to represent a Network Interface made up of a name, and a list of addresses assigned to the interface. In Beta 3, the following API changes are being made to position the IP address oriented methods as convenience methods in aniticipation of supporting generic address types in future releases.

  getInetAddresses
  getByInetAddress
  

  Method getByInetAddress replaces old method getByAddress.

  This change was made to address bug 4503650.

• The componentized constructors of class java.net.URL do not perform syntactic parsing. To highlight this fact, the API specifications for the following contructors now state explicitly that they do not perform validation of inputs.

  • URL(String protocol, String host, int port, String file)
  • URL(String protocol, String host, String file)
  • URL(String protocol, String host, int port, String file, URLStreamHandler handler)

This change was made to address bug 4492314.

The following changes to the Javadoc tool in J2SE 1.4 Beta 3.

• The @throws documentation is copied from an overridden method to a subclass only when the exception is explicitly declared in the overridden method. In javadoc 1.3, the @throws text would always be copied to an overriding method, which is improper in some cases. This new behavior may remove some places where @throws was properly documented. You can use {@inheritDoc} to cause @throws to inherit documentation. (4317583)

• Javadoc tags @return, @param, and @throws are now individually inherited. In javadoc 1.3, they would be inherited only if the entire doc comment was empty. The @see tag is also inherited, but only if there are no @see tags in the overriding element. (4496270)

• Javadoc now documents the values of constant fields. Those values appear on a separate page, reachable from "See also: Constant Values" links by each static field. There is now an inline tag @value for inserting the value into a doc comment. (4422788)